![]() |
|
|
|
Home About Us A-Z Index Search Inquiries Register Press Shop |
|
Organization | |
---|---|
Author |
Product Identification | Version/Release Number | Product Supplier |
---|---|---|
Testing Environment | Binary-compatible Family | Portability Environment | Indicator of Compliance | Compliance Details |
---|---|---|---|---|
None. | Test Suite:
Test Report: |
Question 1: Which of the following XSI Option Groups are supported by the implementation?
Response
Encryption |
|
Realtime |
|
Advanced Realtime |
|
Realtime Threads |
|
Advanced Realtime Threads |
|
Tracing |
|
XSI STREAMS |
|
Legacy |
|
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 6.
If an implementation does not support an Option Group then the system need not support the functions or functional behavior.
Rationale
Base Definitions, Issue 6 states that the system may provide one or more of the XSI Option Groups listed.
Reference
Technical Standard, Base Definitions, Issue 6, Section 2.1.4, XSI Conformance and Section 2.1.5, Option Groups.
Internationalized System Calls and Libraries Extended V3 Product Standard.
Question 2: Which of the following options are supported by the implementation?
Response
IEC 60559 Floating-Point option |
|
IPV6 |
|
Raw Sockets |
|
Support for these options enables additional semantics for interfaces as described in the relevant descriptions in System Interfaces, Issue 6.
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 6, Section 2.1.4, XSI Conformance and Section 2.1.6, Options.
Internationalized System Calls and Libraries Extended V3 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. | |
_POSIX_NO_TRUNC | Pathname components longer than {NAME_MAX) generate an error. |
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 6, 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. |
|
FLT_MANT_DIG | Number of base-FLT_RADIX digits in the float significand. |
|
DBL_MANT_DIG | Number of base-FLT_RADIX digits in the double significand. |
|
LDBL_MANT_DIG | Number of base-FLT_RADIX digits in the long double significand. |
|
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. |
|
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. |
|
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. |
|
FLT_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised float. |
|
DBL_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised double. |
|
LDBL_MIN_EXP | Minimum negative integer such that FLT_RADIX raised to that power minus 1 is a normalised long double. |
|
FLT_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised floats. |
|
DBL_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised doubles. |
|
LDBL_MIN_10_EXP | Minimum negative integer such that 10 raised to that power is in the range of normalised long doubles. |
|
FLT_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite float. |
|
DBL_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite double. |
|
LDBL_MAX_EXP | Maximum integer such that FLT_RADIX raised to that power minus 1 is a representable finite long double. |
|
FLT_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite floats. |
|
DBL_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite doubles. |
|
LDBL_MAX_10_EXP | Maximum integer such that 10 raised to that power is in the range of representable finite long doubles. |
|
FLT_MAX | Maximum representable finite float. |
|
DBL_MAX | Maximum representable finite double. |
|
LDBL_MAX | Maximum representable finite long double. |
|
FLT_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a float. |
|
DBL_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a double. |
|
LDBL_EPSILON | Difference between 1.0 and the least value greater than 1.0 that is representable as a long double. |
|
FLT_MIN | Minimum normalised positive float. |
|
DBL_MIN | Minimum normalised positive double. |
|
LDBL_MIN | Minimum normalised positive long double. |
|
Rationale
This set of constants provides useful information regarding the underlying architecture of the implementation.
Reference
Technical Standard, Base Definitions, Issue 6, 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 |
---|---|---|---|
ARG_MAX | Maximum length of argument to the exec functions including the environment data. | ||
ATEXIT_MAX | Maximum number of functions that may be registered with atexit(). | ||
CHILD_MAX | Maximum number of processes per user ID. | ||
FILESIZEBITS | Minimum number of bits needed to represent as a signed integer value the maximum size of a regular file. | ||
HOST_NAME_MAX | Maximum length of a host name as returned from gethostname(). | ||
IOV_MAX | Maximum number of iovec structures that one process has available for use with readv() or writev(). | ||
LINK_MAX | Maximum number of links to a single file. | ||
LOGIN_NAME_MAX | Maximum length of a login name. | ||
MAX_CANON | Maximum number of bytes in a terminal canonical input line. | ||
MAX_INPUT | Maximum number of bytes for which space will be available in a terminal input queue. | ||
NAME_MAX | Maximum number of bytes in a filename (not including terminating null). | ||
OPEN_MAX | Maximum number of open files that one process can have open at any one time. | ||
PAGESIZE | Size of a page in bytes. | ||
PAGE_SIZE | Same as PAGESIZE. If either PAGESIZE or PAGE_SIZE is defined, the other will be defined with the same value. | ||
PATH_MAX | Maximum number of bytes in a pathname (including the terminating null). | ||
PIPE_BUF | Maximum number of bytes that is guaranteed to be atomic when writing to a pipe. | ||
PTHREAD_DESTRUCTOR_ITERATIONS | Maximum number of attempts made to destroy a thread's thread-specific data values on thread exit. | ||
PTHREAD_KEYS_MAX | Maximum number of data keys that can be created by a process. | ||
PTHREAD_STACK_MIN | Minimum size in bytes of thread stack storage. | ||
PTHREAD_THREADS_MAX | Maximum number of threads that can be created by a process. | ||
STREAM_MAX | Number of streams that one process can have open at one time. | ||
SYMLINK_MAX | Number of bytes in a symbolic link. | ||
SYMLOOP_MAX | Number of symbolic links that can be reliably traversed in the resolution of a pathname in the absence of a loop. | ||
TTY_NAME_MAX | Maximum length of terminal device name. | ||
TZNAME_MAX | Maximum number of bytes supported for the name of a time zone. |
Rationale
Each of these limits can vary within bounds set by the Base Definitions, Issue 6. The minimum permitted value is specified in Chapter 13, <limits.h>.
Reference
Technical Standard, Base Definitions, Issue 6, 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. | ||
BC_DIM_MAX | Maximum number of elements permitted in an array by the bc utility. | ||
BC_SCALE_MAX | Maximum scale value allowed by the bc utility. | ||
BC_STRING_MAX | Maximum length of a string constant accepted by the bc utility. | ||
CHARCLASS_NAME_MAX | Maximum number of bytes in a character class name. | ||
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. | ||
EXPR_NEST_MAX | Maximum number of expressions that can be nested within parentheses by the expr utility. | ||
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. | ||
NGROUPS_MAX | Maximum number of simultaneous supplementary group IDs per process. | ||
RE_DUP_MAX | Maximum number of repeated occurrences of a regular expression permitted when using interval notation. |
Rationale
Each of these limits can vary within bounds set by the Base Definitions, Issue 6. 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 6, 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. |
|
INT_MAX | Maximum value of an int. |
|
LONG_BIT | Number of bits in a long int. |
|
LONG_MAX | Maximum value of a long int. |
|
LLONG_MAX | Maximum value of a long long. |
|
MB_LEN_MAX | Maximum number of bytes in a character, for any supported locale. |
|
SHRT_MAX | Maximum value of a short. |
|
SSIZE_MAX | Maximum value of an object of type ssize_t. |
|
UINT_MAX | Maximum value of an unsigned int. |
|
ULONG_MAX | Maximum value of an unsigned long int. |
|
ULLONG_MAX | Maximum value of a unsigned long long. |
|
USHRT_MAX | Maximum value of an unsigned short int. |
|
WORD_BIT | Number of bits in a word or int. |
|
Rationale
This set of constants provides useful information regarding the underlying architecture of the implementation.
Reference
Technical Standard, Base Definitions, Issue 6, 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. |
|
FOPEN_MAX | Number of streams which the implementation guarantees can be open simultaneously. |
|
L_ctermid | Maximum size of character array to hold ctermid() output. |
|
L_tmpnam | Maximum size of character array to hold tmpnam() output. |
|
TMP_MAX | Minimum number of unique filenames generated by tmpnam(), which is the maximum number of times an application can call tmpnam() reliably. |
|
Rationale
This set of constants provides useful information about the implementation.
Reference
Technical Standard, Base Definitions, Issue 6, Chapter 13, Headers, <stdio.h>.
Question 9: Which of the following option errors, ( denoted by "may fail" within the specification ), listed in System Interfaces, Issue 6 are detected in the circumstances specified?
Response
Function | Error | Detected |
---|---|---|
accept() | EINVAL |
|
ENOMEM |
|
|
EPROTO |
|
|
access() | EINVAL |
|
ENAMETOOLONG |
|
|
ETXTBSY |
|
|
asin() * | Range Error |
|
asinh() * | Range Error |
|
atan() * | Range Error |
|
atanh() * | Range Error |
|
atan2() * | Range Error |
|
bind() | EACCESS |
|
EINVAL |
|
|
EISCONN |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ENOBUFS |
|
|
catclose() | EBADF |
|
EINTR |
|
|
catgets() | EBADF |
|
EBADMSG |
|
|
EINTR |
|
|
EINVAL |
|
|
ENOMSG |
|
|
catopen() | EACCES |
|
EMFILE |
|
|
ENAMETOOLONG |
|
|
ENFILE |
|
|
ENOENT |
|
|
ENOMEM |
|
|
ENOTDIR |
|
|
cfsetispeed() | EINVAL |
|
cfsetospeed() | EINVAL |
|
chdir() | ENAMETOOLONG |
|
ELOOP |
|
|
chmod() | EINTR |
|
EINVAL |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
chown() | EINTR |
|
EINVAL |
|
|
EIO |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
close() | EIO |
|
closedir() | EBADF |
|
EINTR |
|
|
connect() | EACCESS |
|
EADDRINUSE |
|
|
ECONNRESET |
|
|
EHOSTUNREACH |
|
|
EINVAL |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ENETDOWN |
|
|
ENOBUFS |
|
|
EOPNOTSUP |
|
|
endpwent() | EIO |
|
erf() * | Range Error |
|
erfc() * | Range Error |
|
exec | ELOOP |
|
ENAMETOOLONG |
|
|
ENOMEM |
|
|
ETXTBSY |
|
|
exp() * | Range Error |
|
exp2() * | Range Error |
|
expm1() * | Range Error |
|
fchdir() | EINTR |
|
EIO |
|
|
fchmod() | EINTR |
|
EINVAL |
|
|
fchown() | EINVAL |
|
EIO |
|
|
EINTR |
|
|
fclose() | ENXIO |
|
fcntl() | EDEADLK |
|
fdim() * | Range Error |
|
fdopen() | EBADF |
|
EINVAL |
|
|
EMFILE |
|
|
ENOMEM |
|
|
fflush() | ENXIO |
|
fgetc() | ENOMEM |
|
ENXIO |
|
|
fgetpos() | EBADF |
|
ESPIPE |
|
|
fgetwc() | ENOMEM |
|
ENXIO |
|
|
fileno() | EBADF |
|
fma() * | Domain Error |
|
Range Error |
|
|
fmod() * | Range Error |
|
fopen() | EINVAL |
|
ELOOP |
|
|
EMFILE |
|
|
ENAMETOOLONG |
|
|
ENOMEN |
|
|
ETXTBSY |
|
|
fork() | ENOMEM |
|
fpathconf() | EBADF |
|
EINVAL |
|
|
fprintf() | EINVAL |
|
EILSEQ |
|
|
ENOMEM |
|
|
fputc() | ENOMEM |
|
ENXIO |
|
|
fputwc() | ENOMEM |
|
ENXIO |
|
|
fread() | ENOMEM |
|
ENXIO |
|
|
freopen() | EINVAL |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ENOMEM |
|
|
ENXIO |
|
|
ETXTBSY |
|
|
fscanf() | EILSEQ |
|
EINVAL |
|
|
ENOMEM |
|
|
ENXIO |
|
|
fstat() | EOVERFLOW |
|
ftell() | ESPIPE |
|
ftok() | ELOOP |
|
ENAMETOOLONG |
|
|
ftw() | EINVAL |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
fwide() | EBADF |
|
fwprintf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
EINVAL |
|
|
fwscanf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
EINVAL |
|
|
getcwd() | EACCES |
|
ENOMEM |
|
|
getgrent() | EINTR |
|
EIO |
|
|
EMFILE |
|
|
ENFILE |
|
|
getgrgid() | EIO |
|
EINTR |
|
|
EMFILE |
|
|
ENFILE |
|
|
getgrgid_r() | ERANGE |
|
getgrnam() | EIO |
|
EINTR |
|
|
EMFILE |
|
|
ENFILE |
|
|
getgrnam_r() | ERANGE |
|
getitimer() | EINVAL |
|
getlogin() | EMFILE |
|
ENFILE |
|
|
ENXIO |
|
|
getlogin_r() | ERANGE |
|
getpeername() | ENOBUFS |
|
getpgid() | EINVAL |
|
getpwent() | EIO |
|
EMFILE |
|
|
ENFILE |
|
|
getpwnam() | EIO |
|
EINTR |
|
|
EMFILE |
|
|
ENFILE |
|
|
getpwnam_r() | ERANGE |
|
getpwuid() | EIO |
|
EINTR |
|
|
EMFILE |
|
|
ENFILE |
|
|
getpwuid_r() | ERANGE |
|
getsockname() | EINVAL |
|
ENOBUFS |
|
|
getsockopt() | EACCESS |
|
EINVAL |
|
|
ENOBUFS |
|
|
grantpt() | EBADF |
|
EINVAL |
|
|
EACCES |
|
|
hcreate() | ENOMEM |
|
hsearch() | ENOMEM |
|
hypot() * | Range Error |
|
iconv() | EBADF |
|
iconv_close() | EBADF |
|
iconv_open() | EMFILE |
|
ENFILE |
|
|
ENOMEM |
|
|
EINVAL |
|
|
if_nameindex() | ENOBUFS |
|
isatty() | EBADF |
|
ENOTTY |
|
|
j0() | Range Error |
|
j1() | Range Error |
|
jn() | Range Error |
|
lchown() | EIO |
|
EINTR |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ldexp() * | Range Error |
|
link() | ELOOP |
|
ENAMETOOLONG |
|
|
listen() | EACCESS |
|
EINVAL |
|
|
ENOBUFS |
|
|
lockf() | EAGAIN |
|
EDEADLK |
|
|
EINVAL |
|
|
ENOLCK |
|
|
EOPNOTSUPP |
|
|
log1p() * | Range Error |
|
lstat() | ELOOP |
|
ENAMETOOLONG |
|
|
EOVERFLOW |
|
|
mblen() | EILSEQ |
|
mbrlen() | EINVAL |
|
EILSEQ |
|
|
mbrtowc() | EINVAL |
|
EILSEQ |
|
|
mbsrtowcs() | EINVAL |
|
EILSEQ |
|
|
mbstowcs() | EILSEQ |
|
mbtowc() | EILSEQ |
|
mkdir() | ELOOP |
|
ENAMETOOLONG |
|
|
mkfifo() | ELOOP |
|
ENAMETOOLONG |
|
|
mknod() | ELOOP |
|
ENAMETOOLONG |
|
|
nftw() | ELOOP |
|
EMFILE |
|
|
ENAMETOOLONG |
|
|
ENFILE |
|
|
open() | EAGAIN |
|
EINVAL |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ENOMEM |
|
|
ETXTBSY |
|
|
opendir() | ELOOP |
|
EMFILE |
|
|
ENAMETOOLONG |
|
|
ENFILE |
|
|
pathconf() | EACCES |
|
EINVAL |
|
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ENOENT |
|
|
ENOTDIR |
|
|
popen() | EMFILE |
|
EINVAL |
|
|
posix_openpt() | EINVAL |
|
EAGAIN |
|
|
pow() * | Range Error |
|
pread() | ENXIO |
|
printf() | ENOMEM |
|
pthread_attr_setstack() | EACCESS |
|
EINVAL |
|
|
pthread_cancel() | ESRCH |
|
pthread_cond_broadcast() | EINVAL |
|
pthread_cond_destroy() | EBUSY |
|
EINVAL |
|
|
pthread_cond_init() | EBUSY |
|
EINVAL |
|
|
pthread_cond_signal() | EINVAL |
|
pthread_cond_timedwait() | EINVAL |
|
pthread_cond_wait() | EINVAL |
|
pthread_condattr_destroy() | EINVAL |
|
pthread_condattr_setpshared() | EINVAL |
|
pthread_join() | EDEADLK |
|
pthread_key_delete() | EINVAL |
|
pthread_mutex_destroy() | EBUSY |
|
EINVAL |
|
|
pthread_mutex_init() | EBUSY |
|
EINVAL |
|
|
pthread_mutex_lock() | EINVAL |
|
EAGAIN |
|
|
EDEADLK |
|
|
pthread_mutex_trylock() | EINVAL |
|
EAGAIN |
|
|
pthread_mutex_unlock() | EINVAL |
|
EAGAIN |
|
|
EPERM |
|
|
pthread_mutexattr_destroy() | EINVAL |
|
pthread_mutexattr_gettype() | EINVAL |
|
pthread_mutexattr_init() | ENOMEM |
|
pthread_mutexattr_setpshared() | EINVAL |
|
pthread_mutexattr_settype() | EINVAL |
|
pthread_once() | EINVAL |
|
pthread_rwlock_destroy() | EBUSY |
|
EINVAL |
|
|
pthread_rwlock_init() | EBUSY |
|
EINVAL |
|
|
pthread_rwlock_rdlock() | EINVAL |
|
EDEADLK |
|
|
EAGAIN |
|
|
pthread_rwlock_tryrdlock() | EINVAL |
|
EAGAIN |
|
|
pthread_rwlock_trywrlock() | EINVAL |
|
pthread_rwlock_unlock() | EINVAL |
|
EPERM |
|
|
pthread_rwlock_wrlock() | EINVAL |
|
EDEADLK |
|
|
pthread_rwlockattr_destroy() | EINVAL |
|
pthread_rwlockattr_setpshared() | EINVAL |
|
pthread_setcancelstate() | EINVAL |
|
pthread_setcanceltype() | EINVAL |
|
pthread_setspecific() | EINVAL |
|
putc() | ENOMEM |
|
ENXIO |
|
|
putchar() | ENOMEM |
|
ENXIO |
|
|
putenv() | ENOMEM |
|
puts() | ENOMEM |
|
ENXIO |
|
|
pututxline() | EPERM |
|
putwc() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
putwchar() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
pwrite() | EINVAL |
|
ENXIO |
|
|
read() | EIO |
|
ENOBUFS |
|
|
ENOMEM |
|
|
ENXIO |
|
|
readdir() | EBADF |
|
ENOENT |
|
|
readdir_r() | EBADF |
|
readlink() | EACCES |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
readv() | EINVAL |
|
realpath() | ELOOP |
|
ENAMETOOLONG |
|
|
ENOMEM |
|
|
recv() | EIO |
|
ENOBUFS |
|
|
ENOMEM |
|
|
recvfrom() | EIO |
|
ENOBUFS |
|
|
ENOMEM |
|
|
recvmsg() | EIO |
|
ENOBUFS |
|
|
ENOMEM |
|
|
remove() | EBUSY |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ETXTBSY |
|
|
rename() | EBUSY |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ETXTBSY |
|
|
rmdir() | ELOOP |
|
ENAMETOOLONG |
|
|
round() * | Range Error |
|
scalb() * | Range Error |
|
send() | EACCESS |
|
EIO |
|
|
ENETDOWN |
|
|
ENETUNREACH |
|
|
ENOBUFS |
|
|
sendmsg() | EACCESS |
|
EDESTADDRREQ |
|
|
EHOSTUNREACH |
|
|
EIO |
|
|
EISCONN |
|
|
ENETDOWN |
|
|
ENETUNREACH |
|
|
ENOBUFS |
|
|
ENOMEM |
|
|
sendto() | EACCESS |
|
EDESTADDRREQ |
|
|
EHOSTUNREACH |
|
|
EIO |
|
|
EISCONN |
|
|
ENETDOWN |
|
|
ENETUNREACH |
|
|
ENOBUFS |
|
|
ENOMEM |
|
|
setitimer() | EINVAL |
|
setpriority() | EPERM |
|
EACCES |
|
|
setpwent() | EIO |
|
EMFILE |
|
|
ENFILE |
|
|
setrlimit() | EINVAL |
|
setsockopt() | ENOMEM |
|
ENOBUFS |
|
|
setvbuf() | EBADF |
|
shmctl() | EOVERFLOW |
|
shutdown() | ENOBUFS |
|
sigaction() | EINVAL |
|
sigaddset() | EINVAL |
|
sigdelset() | EINVAL |
|
sigismember() | EINVAL |
|
signal() | EINVAL |
|
sigwait() | EINVAL |
|
sin() * | Range Error |
|
sinh() * | Range Error |
|
socket() | EACCESS |
|
ENOBUFS |
|
|
ENOMEM |
|
|
socketpair() | EACCESS |
|
ENOBUFS |
|
|
ENOMEM |
|
|
stat() | ELOOP |
|
ENAMETOOLONG |
|
|
EOVERFLOW |
|
|
statvfs() | ELOOP |
|
ENAMETOOLONG |
|
|
strcoll() | EINVAL |
|
strdup() | ENOMEM |
|
strerror() | EINVAL |
|
strerror_r() | ERANGE |
|
strtod() | EINVAL |
|
strtoimax() | EINVAL |
|
strtol() | EINVAL |
|
strtoumax() | EINVAL |
|
strtoul() | EINVAL |
|
strxfrm() | EINVAL |
|
swprintf() | EILSEQ |
|
EINVAL |
|
|
swcsanf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
symlink() | ELOOP |
|
ENAMETOOLONG |
|
|
system() | ECHILD |
|
tan() * | Range Error |
|
tanh() * | Range Error |
|
tcdrain() | EIO |
|
tcflow() | EIO |
|
tcflush() | EIO |
|
tcsendbreak() | EIO |
|
tcsetattr() | EIO |
|
tmpfile() | EMFILE |
|
ENOMEM |
|
|
towctrans() | EINVAL |
|
truncate() | ELOOP |
|
ENAMETOOLONG |
|
|
ttyname() | EBADF |
|
ENOTTY |
|
|
ttyname_r() | EBADF |
|
ENOTTY |
|
|
ERANGE |
|
|
ungetwc() | EILSEQ |
|
unlink() | EBUSY |
|
ELOOP |
|
|
ENAMETOOLONG |
|
|
ETXTBSY |
|
|
unlockpt() | EBADF |
|
EINVAL |
|
|
usleep() | EINVAL |
|
utime() | ELOOP |
|
ENAMETOOLONG |
|
|
utimes() | ELOOP |
|
ENAMETOOLONG |
|
|
vfscanf() | EILSEQ |
|
EINVAL |
|
|
ENOMEM |
|
|
ENXIO |
|
|
vfwprintf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
EINVAL |
|
|
vfwscanf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
EINVAL |
|
|
wcrtomb() | EINVAL |
|
EILSEQ |
|
|
wcscoll() | EINVAL |
|
wcsrtombs() | EINVAL |
|
EILSEQ |
|
|
wcstod() | EINVAL |
|
wcstoimax() | EINVAL |
|
wcstoumax() | EINVAL |
|
wcstol() | EINVAL |
|
wcstombs() | EILSEQ |
|
wcstoul() | EINVAL |
|
wcsxfrm() | EINVAL |
|
wctrans() | EINVAL |
|
wprintf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
EINVAL |
|
|
write() | EINVAL |
|
ENETDOWN |
|
|
ENETUNREACH |
|
|
ENXIO |
|
|
writev() | EINVAL |
|
wscanf() | ENOMEM |
|
ENXIO |
|
|
EILSEQ |
|
|
y0() | Domain Error |
|
Range Error |
|
|
y1() | Domain Error |
|
Range Error |
|
|
yn() | Domain Error |
|
Range Error |
|
Rationale
Each of the above error conditions is marked as optional in System Interfaces, Issue 6 and an implementation may return this error in the circumstances specified or may not provide the error indication.
Reference
Technical Standard, System Interfaces, Issue 6, Section 2.3, Error Numbers.
Question 10: What format of floating-point numbers is supported by this implementation?
Response
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 6, Section 1.7, 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
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 6, Chapter 13, Headers, <fenv.h>.
Question 12: Which floating-point rounding directions are supported by this implementation for the fegetround(), and fesetround() functions?
Response
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 6, Chapter 13, Headers, <fenv.h>.
Question 13: Is a non-stop floating-point exception mode supported by this implementation?
Response
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 6, Chapter 3, System Interfaces, feholdexcept().
Question 15: Are the optional data encryption interfaces provided?
Response
Function | Provided |
---|---|
crypt() |
|
encrypt() |
|
setkey() |
|
Export Restrictions:
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 6, Section 2, Conformance.
Question 15: Which file types (regular, directory, FIFO, special and so on) are considered to be executable?
Response
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 6, Chapter 3, System Interfaces, exec.
Question 16: What file access control mechanisms does the implementation provide?
Response
Rationale
System Interfaces, Issue 6 notes that implementations may provide additional or alternate file access control mechanisms, or both.
Reference
Technical Standard, Base Definitions, Issue 6, Chapter 4, General Concepts, Section 4.4, File Access Permissions.
Question 17: Are any additional or alternate file access control mechanisms implemented that could cause fstat() or stat() to fail?
Response
Rationale
System Interfaces, Issue 6 notes that there could be an interaction between additional and alternate access controls and the success of fstat() 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 6, Chapter 3, System Interfaces, fstat() and stat().
Question 18: What coded character sets are supported by the implementation?
Response
Rationale
Base Definitions, Issue 6 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 6, Chapter 6, Character Set.
Question 19: What is the implementation's underlying internal codeset?
Response
Rationale
It is useful to be aware of the underlying codeset of the implementation.
Reference
Technical Standard, Base Definitions, Issue 6, Chapter 6, Character Set.
Question 20: Does closing the master side of a pseudo-terminal flush all queued input and output?
Response
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 6, Chapter 3, System Interfaces, close().
Question 21: Does closing the slave side of a pseudo-terminal cause a zero-length message to be sent to the master?
Response
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 6, Chapter 3, System Interfaces, close().
Question 22: What naming conventions are associated with the master side of pseudo-terminal devices?
Response
Rationale
This information is not specified in System Interfaces, Issue 6, and needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 3, System Interfaces, open().
Question 23: What types of file can be polled?
Response
Rationale
Conformance requires that the poll() function supports regular files, terminals, pseudo-terminals, STREAMS, sockets, FIFOs, and pipes. The behaviour of poll() with regards to other file types needs to be defined.
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 3, System Interfaces, poll().
Question 24: What is the direction of stack growth?
Response
From lower to higher addresses. From higher to lower addresses.
Rationale
The specification does not define the direction of stack growth but an application needs this information to define an alternate stack for signals.
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 3, System Interfaces, sigaltstack(). Conformance requires that an implementation supports alternate signal stacks. The APPLICATION USAGE section of the sigaltstack() entry describes one method using malloc() to perform this function. However, the specification does not guarantee that malloc'ed space can be used in this way, nor does it define a specific alternate stack allocation routine.
Question 25: Which of the following si_code values may be generated?
Response
Signal | Code | Generated? |
---|---|---|
SIGILL | ILL_ILLOPC |
|
ILL_ILLOPN |
|
|
ILLL_ILLADR |
|
|
ILL_ILLTRP |
|
|
ILL_PRVOPC |
|
|
ILL_PRVREG |
|
|
ILL_COPROC |
|
|
ILL_BADSTK |
|
|
SIGFPE | FPE_INTDIV |
|
FPE_INTOVF |
|
|
FPE_FLTDIV |
|
|
FPE_FLTOVF |
|
|
FPE_FLTUND |
|
|
FPE_FLTRES |
|
|
FPE_FLTINV |
|
|
FPE_FLTSUB |
|
|
SIGSEGV | SEGV_MAPERR |
|
SEGV_ACCERR |
|
|
SIGBUS | BUS_ADRALN |
|
BUS_ADRERR |
|
|
BUS_OBJERR |
|
|
SIGTRAP | TRAP_BRKPT |
|
TRAP_TRACE |
|
|
SIGCHLD | CLD_EXITED |
|
CLD_KILLED |
|
|
CLD_DUMPED |
|
|
CLD_TRAPPED |
|
|
CLD_STOPPED |
|
|
CLD_CONTINUED |
|
|
SIGPOLL | POLL_IN |
|
POLL_OUT |
|
|
POLL_MSG |
|
|
POLL_ERR |
|
|
POLL_PRI |
|
|
POLL_HUP |
|
|
Any | SI_USER |
|
SI_QUEUE |
|
|
SI_TIMER |
|
|
SI_ASYNCIO |
|
|
SI_MESGQ |
|
Rationale
An Internationalized System Calls and Libraries Extended V3 conformant system may contain limitations that prevent some of the above values from being generated.
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 13, Headers, <signal.h>.
Question 26: Does the setpgrp() function create a new session?
Response
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 6, Chapter 3, System Interfaces, setpgrp().
Question 27: Does the implementation generate a core file when the following signals are delivered to a process?
Response
Signal | Core File Generated |
---|---|
SIGABRT |
|
SIGFPE |
|
SIGILL |
|
SIGQUIT |
|
SIGSEGV |
|
SIGBUS |
|
SIGSYS |
|
SIGTRAP |
|
SIGXCPU |
|
SIGXFSZ |
|
Rationale
Implementation-defined actions, such as creation of a core file, may occur on abnormal termination of a process.
Reference
Technical Standard, Base Definitions, Issue 6, Chapter 13, Headers, <signal.h>.
Question 28: What is the limit the implementation places on the length of a socket's listen queue?
Response
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 6, Chapter 3, listen().
Question 29: 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 |
|
AF_UNIX | N/A | SEQPACKET |
|
AF_UNIX | N/A | DGRAM |
|
AF_INET | TCP | STREAM |
|
AF_INET | UDP | DGRAM |
|
AF_INET6 | TCP | STREAM |
|
AF_INET6 | UDP | DGRAM |
|
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 V3 Product Standard states that conforming products shall be available in configurations that support at least following socket domains:
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 2.10, Sockets.
Product Standard, Internationalized System Calls and Libraries Extended V3.
Question 30: What socket types does the implementation support?
Response
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 6, Chapter 2.10, Sockets, Section 2.10.6, Socket Types.
Question 31: Which functions have cancellation points that occur when a thread is executing?
Response
Function | Cancellation Point? |
---|---|
catclose() |
|
catgets() |
|
catopen() |
|
closedir() |
|
closelog() |
|
ctermid() |
|
dbm_close() |
|
dbm_delete() |
|
dbm_fetch() |
|
dbm_nextkey() |
|
dbm_open() |
|
dbm_store() |
|
dlclose() |
|
dlopen() |
|
endgrent() |
|
endhostent() |
|
endnetent() |
|
endprotoent() |
|
endpwent() |
|
endservent() |
|
endutxent() |
|
fclose() |
|
fcntl() |
|
fflush() |
|
fgetc() |
|
fgetpos() |
|
fgets() |
|
fgetwc() |
|
fgetws() |
|
fopen() |
|
fprintf() |
|
fputc() |
|
fputs() |
|
fputwc() |
|
fputws() |
|
fread() |
|
freopen() |
|
fscanf() |
|
fseek() |
|
fseeko() |
|
fsetpos() |
|
ftell() |
|
ftello() |
|
ftw() |
|
fwprintf() |
|
fwrite() |
|
fwscanf() |
|
getc() |
|
getc_unlocked() |
|
getchar() |
|
getchar_unlocked() |
|
getcwd() |
|
getdate() |
|
getgrent() |
|
getgrgid() |
|
getgrgid_r() |
|
getgrnam() |
|
getgrnam_r() |
|
gethostbyaddr() |
|
gethostbyname() |
|
gethostent() |
|
gethostname() |
|
getlogin() |
|
getlogin_r() |
|
getnetbyaddr() |
|
getnetbyname() |
|
getnetent() |
|
getprotobyname() |
|
getprotobynumber() |
|
getprotoent() |
|
getpwent() |
|
getpwnam() |
|
getpwnam_r() |
|
getpwuid() |
|
getpwuid_r() |
|
gets() |
|
getservbyname() |
|
getservbyport() |
|
getservent() |
|
getutxent() |
|
getutxid() |
|
getutxline() |
|
getwc() |
|
getwchar() |
|
getwd() |
|
glob() |
|
iconv_close() |
|
iconv_open() |
|
ioctl() |
|
lseek() |
|
mkstemp() |
|
nftw() |
|
opendir() |
|
openlog() |
|
pclose() |
|
perror() |
|
popen() |
|
printf() |
|
pthread_rwlock_rdlock() |
|
pthread_rwlock_wrlock() |
|
putc() |
|
putc_unlocked() |
|
putchar() |
|
putchar_unlocked() |
|
puts() |
|
pututxline() |
|
putwc() |
|
putwchar() |
|
readdir() |
|
readdir_r() |
|
remove() |
|
rename() |
|
rewind() |
|
rewinddir() |
|
scanf() |
|
seekdir() |
|
semop() |
|
setgrent() |
|
sethostent() |
|
setnetent() |
|
setprotoent() |
|
setpwent() |
|
setutxent() |
|
strerror() |
|
syslog() |
|
tmpfile() |
|
tmpnam() |
|
ttyname() |
|
ttyname_r() |
|
ungetc() |
|
ungetwc() |
|
unlink() |
|
vfprintf() |
|
vfwprintf() |
|
vprintf() |
|
vwprintf() |
|
wprintf() |
|
wscanf() |
|
Rationale
Base Definitions, Issue 6 states that a cancellation point may occur for these functions.
Reference
Technical Standard, System Interfaces, Issue 6, Section 2.9.5.2, Cancellation Points.
Question 32: 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. |
|
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. |
|
The implementation provides a C-language compilation environment with 32-bit int, and 64-bit long, pointer and off_t types. |
|
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. |
|
Rationale
Base Definitions, Issue 6 defines these scenarios as possible C-language compilation environment offerings.
Reference
Technical Standard, Base Definitions, Issue 6, Chapter 13, Headers, <unistd.h>.
Question 33: 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. |
|
The implementation provides an execution environment with 32-bit int, long and pointer types and an off_t type using at least 64 bits. |
|
The implementation provides an execution environment with 32-bit int, and 64-bit long, pointer and off_t types. |
|
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. |
|
Rationale
Base Definitions, Issue 6 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 6, Chapter 13, Headers, <unistd.h>.
Question 34: Does the implementation support _POSIX_PRIORITIZED_IO?
Response
The system does not support _POSIX_PRIORITIZED_IO.
The system supports _POSIX_PRIORITIZED_IO for the following file types:
Rationale
Support for _POSIX_PRIORITIZED_IO is optional.
Reference
Technical Standard, Base Definitions, Issue 6, Section 2.1.5.2
Technical Standard, System Interfaces, Issue 6, Section 2.8
Question 35: If the Realtime Option Group is supported, what asynchronous I/O operations are cancelable with aio_cancel()?
Response
Rationale
The operations which are cancelable are implementation-defined.
Reference
Technical Standard, System Interfaces, Issue 6, Chapter 3, System Interfaces, aio_cancel().
Question 36: If the Realtime Threads Option Group is supported, what scheduling policy is associated with SCHED_OTHER?
Response
Rationale
Base Definitions, Issue 6 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 6, Section 2.8.4, Scheduling Policies.
Question 37: 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.
PTHREAD_SCOPE_PROCESS.
PTHREAD_SCOPE_SYSTEM.
Both PTHREAD_SCOPE_PROCESS and
PTHREAD_SCOPE_SYSTEM.
Rationale
System Interfaces, Issue 6 states that conforming implementations will support PTHREAD_SCOPE_PROCESS, PTHREAD_SCOPE_SYSTEM, or both.
Reference
Technical Standard, System Interfaces, Issue 6, Section 2.9.4, Thread Scheduling Contention Scope.
Question 38: 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.
PTHREAD_SCOPE_PROCESS.
PTHREAD_SCOPE_SYSTEM.
Rationale
The specification defines the default scheduling contention scope as implementation-defined.
Reference
Technical Standard, System Interfaces, Issue 6, Section 2.9.4, Thread Scheduling Attributes.
This appendix contains additional, explanatory material that was provided by the vendor.
Copyright �
All rights reserved.
Date | Name | Comment |
---|---|---|
New |
The Open Group and Boundaryless Information Flow are trademarks
and UNIX is a registered trademark of The Open Group in the United States
and other countries. All other trademarks are the property of their
respective owners.