Organization | IBM Corporation |
---|---|
Author | Manoranjan Sahu |
Product Identification | Version/Release Number | Product Supplier |
---|---|---|
AIX 7 Operating System(PID 5765-G98) | AIX version 7, at either 7.2 TL5 (or later) | International Business Machine Corporation |
Testing Environment | Binary-compatible Family | Portability Environment | Indicator of Compliance | Compliance Details |
---|---|---|---|---|
IBM System p Server: Model E1C, VIO client. | HARDWARE: Systems using CHRP system architecture with POWER(tm) processors and 2, 8 or 128 port async cards. SOFTWARE: AIX Version 7, at either 7.2 TL5 (or later)with IBM XL C/C++ for AIX, V16.1, installed on JFS2 filesystems and running in 32bit(ILP32_OFF32) mode | None. | Test Report from Test Suite | Test Suite: VSX4.7.17 Test Report: VSX4_journal |
IBM System p Server: Model E1C, VIO client. | HARDWARE: Systems using CHRP system architecture with POWER(tm) processors and 2, 8 or 128 port async cards. SOFTWARE: AIX Version 7, at either 7.2 TL5 (or later)with IBM XL C/C++ for AIX, V16.1, installed on JFS2 filesystems and running in 32bit(ILP32_OFF32) mode | None. | Test Report from Test Suite | Test Suite: VSX5.3.16 Test Report: VSX5_journal |
IBM System p Server: Model E1C, VIO client. | HARDWARE: Systems using CHRP system architecture with POWER(tm) processors and 2, 8 or 128 port async cards. SOFTWARE: AIX Version 7, at either 7.2 TL5 (or later)with IBM XL C/C++ for AIX, V16.1, installed on JFS2 filesystems and running in 32bit(ILP32_OFF32) mode | None. | Test Report from Test Suite | Test Suite: VSRT5.4.18 Test Report: VSRT_journal |
IBM System p Server: Model E1C, VIO client. | HARDWARE: Systems using CHRP system architecture with POWER(tm) processors and 2, 8 or 128 port async cards. SOFTWARE: AIX Version 7, at either 7.2 TL5 (or later)with IBM XL C/C++ for AIX, V16.1, installed on JFS2 filesystems and running in 32bit(ILP32_OFF32) mode | None. | Test Report from Test Suite | Test Suite:
VSTH5.5.16 Test Report: VSTH_journal |
IBM System p Server: Model E1C, VIO client. | HARDWARE: Systems using CHRP system architecture with POWER(tm) processors and 2, 8 or 128 port async cards. SOFTWARE: AIX Version 7, at either 7.2 TL5 (or later)with IBM XL C/C++ for AIX, V16.1, installed on JFS2 filesystems and running in 32bit(ILP32_OFF32) mode | None. | Test Report from Test Suite | Test Suite: VSU5.3.19 Test Report: VSU_journal |
Question 1: Which of the following XSI Option Groups are supported by the implementation?
Response
Encryption | Yes |
Realtime | Yes |
Advanced Realtime | Yes |
Realtime Threads | No |
Advanced Realtime Threads | No |
Tracing | No |
XSI STREAMS | Yes |
Support for an XSI Option Group can only be claimed if all interfaces in that group behave according to the relevant descriptions in System Interfaces, Issue 7.
If an implementation does not support an Option Group then the system need not support the functions or functional behavior.
Rationale
Base Definitions, Issue 7 states that the system may provide one or more of the XSI Option Groups listed.
Reference
Technical Standard, Base Definitions, Issue 7, Section 2.1.4, XSI Conformance and Section 2.1.5.2, XSI Option Groups.
Internationalized System Calls and Libraries Extended V4 Product Standard.
Question 2: Which of the following options are supported by the implementation?
Response
IEC 60559 Floating-Point option | No |
IPV6 | Yes |
Raw Sockets | Yes |
Support for these options enables additional semantics for interfaces as described in the relevant descriptions in System Interfaces, Issue 7.
Rationale
The system may provide support for additional options beyond those required for XSI conformance or covered by the XSI Option Groups.
Reference
Technical Standard, Base Definitions, Issue 7, Section 2.1.4, XSI Conformance and Section 2.1.6, Options.
Internationalized System Calls and Libraries Extended V4 Product Standard.
Question 3: For each of the symbolic constants, specified in the <unistd.h> header file, are the associated features always available on the system?
Response
Macro Name | Meaning | Provided |
---|---|---|
_POSIX_CHOWN_RESTRICTED | The use of chown() is restricted to a process with appropriate privileges, and to changing the group ID of a file only to the effective group ID of the process or one of its supplementary group IDs. | Yes |
_POSIX_NO_TRUNC | Pathname components longer than {NAME_MAX} generate an error. | Yes |
_POSIX2_SYMLINKS | Symbolic links can be created. | Yes |
Rationale
For a conformant implementation, these POSIX features must be provided. In some cases the feature need not be provided for all files or devices supported by the implementation.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <unistd.h>.
Question 4: What are the values associated with the following constants specified in the <float.h> header file?
Response
Macro Name | Meaning | Value |
---|---|---|
FLT_RADIX | Radix of the exponent representation. | 2 |
FLT_MANT_DIG | Number of base-FLT_RADIX digits in the float significand. | 24 |
DBL_MANT_DIG | Number of base-FLT_RADIX digits in the double significand. | 53 |
LDBL_MANT_DIG | Number of base-FLT_RADIX digits in the long double significand. | 106 |
FLT_DIG | Number of decimal digits, q, such that any floating-point number with q digits can be rounded into a float representation and back again without change to the q digits. | 6" |
DBL_DIG | Number of decimal digits, q, such that any floating-point number with q digits can be rounded into a double representation and back again without change to the q digits. | 15 |
LDBL_DIG | Number of decimal digits, q, such that any floating-point number with q digits can be rounded into a long double representation and back again without change to the q digits. | 31 |
FLT_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised float. | -125 |
DBL_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised double. | -1021 |
LDBL_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised long double. | -1021 |
FLT_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised floats. | -37 |
DBL_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised doubles. | -307 |
LDBL_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised long doubles. | -307 |
FLT_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite float. | 128 |
DBL_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite double. | 1024 |
LDBL_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite long double. | 1024 |
FLT_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite floats. | 38 |
DBL_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite doubles. | 308 |
LDBL_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite long doubles. | 308 |
FLT_MAX | Maximum representable finite float. | 3.4028234663852866e+38F |
DBL_MAX | Maximum representable finite double. | 1.7976931348623158e+308 |
LDBL_MAX | Maximum representable finite long double. | 1.7976931348623158e+308 |
FLT_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a float. | 1.1920928955078125e-7F |
DBL_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a double. | 2.2204460492503131e-16 |
LDBL_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a long double. | 2.4651903288156618919116517665087070E-32L |
FLT_MIN | Minimum normalised positive float. | 1.1754943508222875e-38F |
DBL_MIN | Minimum normalised positive double. | 2.2250738585072014e-308 |
LDBL_MIN | Minimum normalised positive long double. | 2.2250738585072014e-308 |
Rationale
This set of constants provides useful information regarding the underlying architecture of the implementation.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <float.h>.
Question 5: What are the values associated with the following constants (optionally specified in the <limits.h> header file)?
Response
Macro Name | Meaning | Minimum | Maximum |
---|---|---|---|
AIO_LISTIO_MAX | Maximum number of I/O operations in a single list I/O call. | 2 | 4096 |
AIO_MAX | Maximum number of outstanding asynchronous I/O operations. | 1 | 4096 |
ARG_MAX | Maximum length of argument to the exec functions including the environment data. | 4096 | 1048576 |
ATEXIT_MAX | Maximum number of functions that may be registered with atexit(). | 32 | 2048 |
CHILD_MAX | Maximum number of processes per user ID. | 25 | 128 |
DELAYTIMER_MAX | Maximum number of timer expiration overruns. | 32 | 32 |
FILESIZEBITS | Minimum number of bits needed to represent as a signed integer value the maximum size of a regular file. | 32 | 45 |
HOST_NAME_MAX | Maximum length of a host name as returned from gethostname(). | 255 | 256 |
IOV_MAX | Maximum number of iovec structures that one process has available for use with readv() or writev(). | 16 | 16 |
LINK_MAX | Maximum number of links to a single file. | 8 | 32767 |
LOGIN_NAME_MAX | Maximum length of a login name. | 9 | 9 |
MAX_CANON | Maximum number of bytes in a terminal canonical input line. | 255 | 256 |
MAX_INPUT | Maximum number of bytes for which space will be available in a terminal input queue. | 255 | 512 |
NAME_MAX | Maximum number of bytes in a filename (not including terminating null). | 14 | 255 |
OPEN_MAX | Maximum number of open files that one process can have open at any one time. | 20 | 65534 |
PAGESIZE | Size of a page in bytes. | 1 | 4096 |
PAGE_SIZE | Same as PAGESIZE. If either PAGESIZE or PAGE_SIZE is defined, the other will be defined with the same value. | 1 | 4096 |
PATH_MAX | Maximum number of bytes in a pathname (including the terminating null). | 16 | 1024 |
PIPE_BUF | Maximum number of bytes that is guaranteed to be atomic when writing to a pipe. | 512 | 32768 |
PTHREAD_DESTRUCTOR_ITERATIONS | Maximum number of attempts made to destroy a thread's thread-specific data values on thread exit. | 4 | 4 |
PTHREAD_KEYS_MAX | Maximum number of data keys that can be created by a process. | 128 | 450 |
PTHREAD_STACK_MIN | Minimum size in bytes of thread stack storage. | 0 | 8192 |
PTHREAD_THREADS_MAX | Maximum number of threads that can be created by a process. | 64 | 512 |
RE_DUP_MAX | Maximum number of repeated occurrences of a BRE or ERE interval expression. | 255 | 255 |
RTSIG_MAX | Maximum number of realtime signals reserved for application use. | 8 | 8 |
SEM_NSEMS_MAX | Maximum number of semaphores that a process may have. | 256 | 32768 |
SEM_VALUE_MAX | The maximum value a semaphore may have. | 32767 | 32767 |
SIGQUEUE_MAX | Maximum number of pending queued signals. | 32 | 32 |
STREAM_MAX | Number of streams that one process can have open at one time. | 8 | 32767 |
SYMLINK_MAX | Number of bytes in a symbolic link. | 255 | 255 |
SYMLOOP_MAX | Number of symbolic links that can be reliably traversed in the resolution of a pathname in the absence of a loop. | 8 | 20 |
TIMER_MAX | Maximum number of timers per process. | 32 | 32 |
TTY_NAME_MAX | Maximum length of terminal device name. | 9 | 1024 |
TZNAME_MAX | Maximum number of bytes supported for the name of a time zone. | 6 | 255 |
Rationale
Each of these limits can vary within bounds set by the Base Definitions, Issue 7. The minimum permitted value is specified in Chapter 13, <limits.h>.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <limits.h>.
Question 6: What are the values associated with the following constants specified in the <limits.h> header file?
Response
Macro Name | Meaning | Minimum | Maximum |
---|---|---|---|
BC_BASE_MAX | Maximum ibase and obase values allowed by the bc utility. | 99 | 99 |
BC_DIM_MAX | Maximum number of elements permitted in an array by the bc utility. | 2048 | 2048 |
BC_SCALE_MAX | Maximum scale value allowed by the bc utility. | 99 | 99 |
BC_STRING_MAX | Maximum length of a string constant accepted by the bc utility. | 1000 | 2048 |
CHARCLASS_NAME_MAX | Maximum number of bytes in a character class name. | 14 | 14 |
COLL_WEIGHTS_MAX | Maximum number of weights that can be assigned to an entry of the LC_COLLATE order keyword in the locale definition file. | 2 | 4 |
EXPR_NEST_MAX | Maximum number of expressions that can be nested within parentheses by the expr utility. | 32 | 32 |
LINE_MAX | Maximum length in bytes including the trailing newline of a utility's input line when the utility is described as processing text files. | 2048 | 2048 |
NGROUPS_MAX | Maximum number of simultaneous supplementary group IDs per process. | 8 | 128 |
RE_DUP_MAX | Maximum number of repeated occurrences of a regular expression permitted when using interval notation. | 255 | 255 |
Rationale
Each of these limits can vary within bounds set by the Base Definitions, Issue 7. The minimum value that a limit can take on any conforming system is given in the corresponding _POSIX_ or _POSIX2_ value. A specific conforming implementation may provide a higher minimum value than this and the maximum value that it provides can differ from the minimum. Some conforming implementations may provide a potentially infinite value as the maximum, in which case the value is considered to be indeterminate. The minimum value must always be definitive since the _POSIX_ or _POSIX2_ value provides a known lower bound for the range of possible values.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <limits.h>.
Question 7: What are the values associated with the following numerical constants specified in the <limits.h> header file?
Response
Macro Name | Meaning | Value |
---|---|---|
CHAR_MAX | Maximum value of a char. | 255 |
INT_MAX | Maximum value of an int. | 2147483647 |
LONG_BIT | Number of bits in a long int. | 32 |
LONG_MAX | Maximum value of a long int. | 2147483647 |
LLONG_MAX | Maximum value of a long long. | 9223372036854775807 |
MB_LEN_MAX | Maximum number of bytes in a character, for any supported locale. | 4 |
SHRT_MAX | Maximum value of a short. | 32767 |
SSIZE_MAX | Maximum value of an object of type ssize_t. | 2147483647 |
UINT_MAX | Maximum value of an unsigned int. | 4294967295 |
ULONG_MAX | Maximum value of an unsigned long int. | 4294967295 |
ULLONG_MAX | Maximum value of a unsigned long long. | 18446744073709551615 |
USHRT_MAX | Maximum value of an unsigned short int. | 65535 |
WORD_BIT | Number of bits in a word or int. | 32 |
Rationale
This set of constants provides useful information regarding the underlying architecture of the implementation.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <limits.h>.
Question 8: What are the values associated with the following numerical constants specified in the <stdio.h> header file?
Response
Macro Name | Meaning | Value |
---|---|---|
FILENAME_MAX | Maximum size in bytes of the longest filename string that the implementation guarantees can be opened. | 255 |
FOPEN_MAX | Number of streams which the implementation guarantees can be open simultaneously. | 32767 |
L_ctermid | Maximum size of character array to hold ctermid() output. | 9 |
L_tmpnam | Maximum size of character array to hold tmpnam() output. | 20 |
TMP_MAX | Minimum number of unique filenames generated by tmpnam(), which is the maximum number of times an application can call tmpnam() reliably. | 16384 |
Rationale
This set of constants provides useful information about the implementation.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <stdio.h>.
Question 9: What is the resolution of file timestamps in a file system?
Response
Nanoseconds.
Rationale
The resolution of timestamps of files in a file system is implementation-defined, but is no coarser than one-second resolution.
Reference
Technical Standard, Base Definitions, Issue 7, Section 4.9, File Times Update.
Question 10: What format of floating-point numbers is supported by this implementation?
Response
IEEE floating-point format.
Rationale
Most implementations support IEEE floating-point format either in hardware or software. Some implementations support other formats with different exponent and mantissa accuracy. These differences need to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Section 1.1, Relationship to Other Formal Standards.
Question 11: Which floating-point exceptions are supported by this implementation for the fegetexecptflag(), feraiseexcept(), fesetexecptflag(), and fetestexecptflag() functions?
Response
FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW
Rationale
The behavior of a conforming implementation in this area is not mandated in the specification and needs to be defined.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <fenv.h>.
Question 12: Which floating-point rounding directions are supported by this implementation for the fegetround(), and fesetround() functions?
Response
FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD
Rationale
The behavior of a conforming implementation in this area is not mandated in the specification and needs to be defined.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <fenv.h>.
Question 13: Is a non-stop floating-point exception mode supported by this implementation?
Response
Yes
Rationale
The behavior of a conforming implementation in this area is not mandated in the specification and needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, feholdexcept().
Question 14: Are the optional data encryption interfaces provided?
Response
Function | Provided |
---|---|
crypt() | Yes |
encrypt() | Yes |
setkey() | Yes |
Export Restrictions:
None.
Rationale
Normally, an implementation will either provide all three of these routines or will provide none of them at all. If the routines are not provided, then the implementation must provide a dummy interface which always raises an ENOSYS error condition.
It is also possible that the implementation of the encrypt() function may be affected by export restrictions, in which case, the restrictions should be documented here.
For example, historical implementations have supplied all three of these routines outside the U.S.A., but due to export restrictions on the decoding algorithm, a dummy version of encrypt() is provided that does encoding but no decoding.
Reference
Technical Standard, Base Definitions, Issue 7, Section 2.1.5.2, XSI Option Groups.
Question 15: Which file types (regular, directory, FIFO, special and so on) are considered to be executable?
Response
Only regular files may be executed.
Rationale
The EACCES error associated with exec functions occurs in circumstances when the implementation does not support execution of files of the type specified. A list of these file types needs to be provided.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, exec.
Question 16: What file access control mechanisms does the implementation provide?
Response
Access control lists are provided to augment the POSIX access modes. The base access list consists of the standard owner, group and other permissions. Access control lists can be created for regular files, directories, named pipes, message queues, shared memory segments, semaphores and special files.(When chmod() is called and alternate access control methods are disabled, additional file access control methods are disabled as well.) Access control lists are an alternate file access control method.
Rationale
System Interfaces, Issue 7 notes that implementations may provide additional or alternate file access control mechanisms, or both.
Reference
Technical Standard, Base Definitions, Issue 7, Section 4.5, File Access Permissions.
Question 17: Are any additional or alternate file access control mechanisms implemented that could cause fstat(), fstatat(), lstat() or stat() to fail?
Response
Yes
Rationale
System Interfaces, Issue 7 notes that there could be an interaction between additional and alternate access controls and the success of fstat(), fstatat(), lstat(), and stat(). This would suggest that an implementation can allow access to a file but not allow the process to gain information about the status of the file.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, fstat() and fstatat().
Question 18: When mode bit S_ISVTX is set on a directory, can writable files be removed and renamed within the directory?
Response
Yes.
Rationale
Whether or not files that are writable by the process can be removed or renamed within a directory that has mode bit S_ISVTX set is implementation-defined.
Reference
Technical Standard, Base Definitions, Issue 7, Section 4.3, Directory Protection.
Question 19: How does link() handle symbolic links?
Response
It follows the symbolic link
Rationale
If path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, link().
Question 20: What coded character sets are supported by the implementation?
Response
ISO 8859-1, 8859-2, 8859-3, 8859-4, 8859-5, 8859-6, 8859-7, 8859-8, 8859-9 IBM-eucJP(Japanese EUC) IBM-eucKR(Korean EUC) IBM-eucTW(Traditional Chinese EUC) UTF-8(FSS-UTF) IBM-850, IBM-856, IBM-932, IBM-1046, IBM-eucCN TIS-620
Rationale
Base Definitions, Issue 7 states that conforming implementations support one or more coded character sets, and that each of these includes the portable character set.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 6, Character Set.
Question 21: What is the implementation's underlying internal codeset?
Response
AIX supports the IBM-850 codeset as an option
Rationale
It is useful to be aware of the underlying codeset of the implementation.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 6, Character Set.
Question 22: Does closing the master side of a pseudo-terminal flush all queued input and output?
Response
Yes
Rationale
The behaviour of a conforming implementation in this area is not mandated in the specification and needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, close().
Question 23: Does closing the slave side of a STREAMS-based pseudo-terminal cause a zero-length message to be sent to the master?
Response
Yes
Rationale
The behaviour of a conforming implementation in this area is not mandated in the specification and needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, close().
Question 24: What naming conventions are associated with the master side of pseudo-terminal devices?
Response
For BSD ptys: /dev/ptyXN, where X is in the following set; [p-z][A-Z] and N is in the following set; [0-9][a-f]. For AT&T ptys: the clone device is /dev/ptc.
Rationale
This information is not specified in System Interfaces, Issue 7, and needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, open().
Question 25: What types of file can be polled?
Response
Regular files, Terminals, Pseudo-Terminals, STREAMS, Sockets, FIFOs, Pipes
Rationale
Conformance requires that the poll() function supports regular files, terminals, pseudo-terminals, FIFOs, pipes, sockets, and (if the XSI STREAMS option is supported) STREAMS. The behaviour of poll() with regards to other file types needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, poll().
Question 26: Which of the following si_code values may be generated?
Response
Signal | Code | Generated? |
---|---|---|
SIGILL | ILL_ILLOPC | No |
ILL_ILLOPN | No | |
ILLL_ILLADR | No | |
ILL_ILLTRP | No | |
ILL_PRVOPC | No | |
ILL_PRVREG | No | |
ILL_COPROC | No | |
ILL_BADSTK | No | |
SIGFPE | FPE_INTDIV | No |
FPE_INTOVF | No | |
FPE_FLTDIV | No | |
FPE_FLTOVF | No | |
FPE_FLTUND | No | |
FPE_FLTRES | No | |
FPE_FLTINV | No | |
FPE_FLTSUB | No | |
SIGSEGV | SEGV_MAPERR | No |
SEGV_ACCERR | No | |
SIGBUS | BUS_ADRALN | No |
BUS_ADRERR | No | |
BUS_OBJERR | No | |
SIGTRAP | TRAP_BRKPT | No |
TRAP_TRACE | No | |
SIGCHLD | CLD_EXITED | Yes |
CLD_KILLED | Yes | |
CLD_DUMPED | Yes | |
CLD_TRAPPED | No | |
CLD_STOPPED | Yes | |
CLD_CONTINUED | Yes | |
SIGPOLL | POLL_IN | No |
POLL_OUT | No | |
POLL_MSG | No | |
POLL_ERR | No | |
POLL_PRI | No | |
POLL_HUP | No | |
Any | SI_USER | No |
SI_QUEUE | No | |
SI_TIMER | No | |
SI_ASYNCIO | No | |
SI_MESGQ | No |
Rationale
An Internationalized System Calls and Libraries Extended V4 conformant system may contain limitations that prevent some of the above values from being generated.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 13, Headers, <signal.h>.
Question 27: Does the setpgrp() function create a new session?
Response
Yes
Rationale
It is unspecified whether or not a successful call to the setpgrp() function will cause a new session to be created.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, setpgrp().
Question 28: Does the implementation generate a core file when the following signals are delivered to a process and the default action is taken?
Response
Signal | Core File Generated |
---|---|
SIGABRT | No |
SIGFPE | Yes |
SIGILL | Yes |
SIGQUIT | Yes |
SIGSEGV | Yes |
SIGBUS | Yes |
SIGSYS | Yes |
SIGTRAP | Yes |
SIGXCPU | No |
SIGXFSZ | No |
Rationale
Implementation-defined actions, such as creation of a core file, may occur when the default action for the signal is to terminate the process abnormally with additional actions.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.4.3, SIG_DFL.
Question 29: What is the limit the implementation places on the length of a socket's listen queue?
Response
5
Rationale
The specification states that an implementation may limit the length of a socket's listen queue, and that this limit may be imposed if the setting of the backlog argument exceeds an implementation-defined maximum value.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, listen().
Question 30: What combinations of address family, socket types, and protocols does the implementation support?
Response
Address Family | Protocol | Socket Type | Supported? |
---|---|---|---|
AF_UNIX | N/A | STREAM | Yes |
AF_UNIX | N/A | SEQPACKET | No |
AF_UNIX | N/A | DGRAM | No |
AF_INET | TCP | STREAM | Yes |
AF_INET | UDP | DGRAM | Yes |
AF_INET6 | TCP | STREAM | Yes |
AF_INET6 | UDP | DGRAM | Yes |
Rationale
The specification states that the domains, socket types and protocols supported by a conforming system are implementation-defined. The Internationalized System Calls and Libraries Extended V4 Product Standard states that conforming products shall be available in configurations that support at least following socket domains:
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.10, Sockets.
Product Standard, Internationalized System Calls and Libraries Extended V4.
Question 31: What socket types does the implementation support?
Response
SOCK_RAW, SOCK_STREAM, SOCK_SEQPACKET, SOCK_DGRAM
Rationale
The specification states that there are four socket types defined - SOCK_RAW, SOCK_STREAM, SOCK_SEQPACKET and SOCK_DGRAM - but does not state which are required. Implementations may also support additional socket types.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.10.6, Socket Types.
Question 32: Which functions have cancellation points that occur when a thread is executing?
Response
Function | Cancellation Point? |
---|---|
access() | No |
asctime_r() | No |
catclose() | No |
catopen() | No |
chmod() | No |
chown() | No |
closedir() | No |
closelog() | No |
ctermid() | No |
ctime_r() | No |
dlclose() | No |
dlopen() | No |
dprintf() | No |
endhostent() | No |
endnetent() | No |
endprotoent() | No |
endservent() | No |
faccessat() | No |
fchmod() | No |
fchmodat() | No |
fchown() | No |
fchownat() | No |
fclose() | No |
fcntl() | No |
fflush() | No |
fgetc() | No |
fgetpos() | No |
fgets() | No |
fgetwc() | No |
fgetws() | No |
fmtmsg() | No |
fopen() | No |
fpathconf() | No |
fprintf() | No |
fputc() | No |
fputs() | No |
fputwc() | No |
fputws() | No |
fread() | No |
freopen() | No |
fscanf() | No |
fseek() | No |
fseeko() | No |
fsetpos() | No |
fstat() | No |
fstatat() | No |
ftell() | No |
ftello() | No |
futimens() | No |
fwprintf() | No |
fwrite() | No |
fwscanf() | No |
getaddrinfo() | No |
getc() | No |
getc_unlocked() | No |
getchar() | No |
getchar_unlocked() | No |
getcwd() | No |
getdelim() | No |
getgrgid_r() | No |
getgrnam_r() | No |
gethostid() | No |
gethostname() | No |
getline() | No |
getlogin_r() | No |
getnameinfo() | No |
getpwnam_r() | No |
getpwuid_r() | No |
gets() | No |
getwc() | No |
getwchar() | No |
glob() | No |
iconv_close() | No |
iconv_open() | No |
ioctl() | No |
link() | No |
linkat() | No |
lio_listio() | No |
localtime_r() | No |
lockf() | No |
lseek() | No |
lstat() | No |
mkdir() | No |
mkdirat() | No |
mkdtemp() | No |
mkfifo() | No |
mkfifoat() | No |
mknod() | No |
mknodat() | No |
mkstemp() | No |
mktime() | No |
opendir() | No |
openlog() | No |
pathconf() | No |
perror() | No |
popen() | No |
posix_fadvise() | No |
posix_fallocate() | No |
posix_madvise() | No |
posix_openpt() | No |
posix_spawn() | No |
posix_spawnp() | No |
posix_typed_mem_open() | No |
printf() | No |
psiginfo() | No |
psignal() | No |
pthread_rwlock_rdlock() | No |
pthread_rwlock_timedrdlock() | No |
pthread_rwlock_timedwrlock() | No |
pthread_rwlock_wrlock() | No |
putc() | No |
putc_unlocked() | No |
putchar() | No |
putchar_unlocked() | No |
puts() | No |
putwc() | No |
putwchar() | No |
readdir_r() | No |
readlink() | No |
readlinkat() | No |
remove() | No |
rename() | No |
renameat() | No |
rewind() | No |
rewinddir() | No |
scandir() | No |
scanf() | No |
seekdir() | No |
semop() | No |
sethostent() | No |
setnetent() | No |
setprotoent() | No |
setservent() | No |
sigpause() | No |
stat() | No |
strerror_l() | No |
strerror_r() | No |
strftime() | No |
strftime_l() | No |
syslog() | No |
tmpfile() | No |
tmpnam() | No |
ttyname_r() | No |
tzset() | No |
ungetc() | No |
ungetwc() | No |
unlink() | No |
unlinkat() | No |
utime() | No |
utimensat() | No |
utimes() | No |
vdprintf() | No |
vfprintf() | No |
vfwprintf() | No |
vprintf() | No |
vwprintf() | No |
wcsftime() | No |
wordexp() | No |
wprintf() | No |
wscanf() | No |
Rationale
System Interfaces, Issue 7 states that a cancellation point may occur for these functions.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.9.5.2, Cancellation Points.
Question 33: What C-language compilation environments are provided?
Response
Programming Environment | Provided |
---|---|
The implementation provides a C-language compilation environment with
32-bit int, long, pointer and off_t types. | Yes |
The implementation provides a C-language compilation environment with
32-bit int, long and pointer types and an off_t type using at least 64 bits. | Yes |
The implementation provides a C-language compilation environment with 32-bit int, and 64-bit long, pointer and off_t types. | Yes |
The implementation provides a C-language compilation environment with int using at least 32-bits, and long, pointer and off_t types using at least 64 bits. | Yes |
Rationale
Base Definitions, Issue 7 defines these scenarios as possible C-language compilation environment offerings.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <unistd.h>.
Question 34: What execution environments are provided on the system under test?
Response
Execution Environment | Provided |
---|---|
The implementation provides an execution environment with 32-bit int, long, pointer and off_t types. | Yes |
The implementation provides an execution environment with 32-bit int, long and pointer types and an off_t type using at least 64 bits. | Yes |
The implementation provides an execution environment with 32-bit int, and 64-bit long, pointer and off_t types. | No |
The implementation provides an execution environment with int using at least 32-bits, and long, pointer and off_t types using at least 64 bits. | No |
Rationale
Base Definitions, Issue 7 defines four scenarios as possible C-language compilation environment offerings but does not define which corresponding execution environments are supported.
Reference
Technical Standard, Base Definitions, Issue 7, Chapter 13, Headers, <unistd.h>.
Question 35: If the Realtime Option Group is supported, does the implementation support _POSIX_PRIORITIZED_IO?
Response
The system supports _POSIX_PRIORITIZED_IO for the following file types:
Regular files
Rationale
Support for _POSIX_PRIORITIZED_IO is optional.
Reference
Technical Standard, Base Definitions, Issue 7, Section 2.1.5.2, Realtime
Question 36: What asynchronous I/O operations are cancelable with aio_cancel()?
Response
I/O requests initiated by the following commands are cancel-able if the request has not been started: aio_read() aio_write() lio_listio() with the LIO_WAIT or LIO_NOWAIT mode (other modes are not cancel-able)
Rationale
The operations which are cancelable are implementation-defined.
Reference
Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, aio_cancel().
Question 37: If the Realtime Threads Option Group is supported, what scheduling policy is associated with SCHED_OTHER?
Response
Not Applicable.
Rationale
Base Definitions, Issue 7 states that conforming implementations must support a scheduling policy identified as SCHED_OTHER but define its effects as implementation-defined.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.8.4, Scheduling Policies.
Question 38: If the Realtime Threads Option Group is supported, what scheduling contention scopes are supported: PTHREAD_SCOPE_PROCESS, PTHREAD_SCOPE_SYSTEM, or both?
Response
Not applicable - the Realtime Threads Option Group is not supported.
Rationale
System Interfaces, Issue 7 states that conforming implementations will support PTHREAD_SCOPE_PROCESS, PTHREAD_SCOPE_SYSTEM, or both.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.9.4, Thread Scheduling Contention Scope.
Question 39: If the Realtime Threads Option Group is supported, what is the default scheduling contention scope when a process is created?
Response
Not applicable - the Realtime Threads Option Group is not supported.
Rationale
The specification defines the default scheduling contention scope as implementation-defined.
Reference
Technical Standard, System Interfaces, Issue 7, Section 2.9.4, Thread Scheduling Contention Scope.
This appendix contains additional, explanatory material that was provided by the vendor.
Copyright ©
All rights reserved.
Date | Name | Comment |
---|---|---|
New | Manoranjan Sahu | Initial UNIXv7 Submission for AIX V7.2 TL5 release on 09-2020 |
The Open Group, UNIX and The Open Brand ("X Device")
are registered trademarks of The Open Group in the United States
and other countries. All other trademarks are the property of their
respective owners.