Conformance Statement

Product Standard: Internationalized System Calls and Libraries Extended V4

This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:

While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.
Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.
Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.
Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.
Questions on this system should be addressed to the Conformance Statement Manager at The Open Group.

Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.

Organization
Author

1. Internationalized System Calls and Libraries Extended V4

Product Information

Enter the product name, version/release number, and product supplier for each product required to meet the conformance requirements.

Product Identification	Version/Release Number	Product Supplier

Environment Specification

Product registration applies to software products operating in a specific hardware or hardware/software environment.
A product may be registered in all members of a binary-compatible family of products on the basis of a single test report.

Answer the questions for each binary-compatible family. Alternatively, provide the answers in the Appendix at the end of this document or if lengthy provide a separate external html file to The Open Group that can be linked into the Appendix.

Testing Environment	Binary-compatible Family	Portability Environment	Indicator of Compliance	Compliance Details
		None.		Test Suite: Test Report:
		None.		Test Suite: Test Report:
		None.		Test Suite: Test Report:
		None.		Test Suite: Test Report:
		None.		Test Suite: Test Report:

Temporary Waivers

Enter the waiver number and expiry date for each temporary waiver granted by The Open Group.

	Waiver Number	Expiry Date

1.1 General Attributes

1.1.1 XSI Option Groups

Question 1: Which of the following XSI Option Groups are supported by the implementation?

Response

Encryption	Yes No
Realtime	Yes No
Advanced Realtime	Yes No
Realtime Threads	Yes No
Advanced Realtime Threads	Yes No
Tracing	Yes No
XSI STREAMS	Yes No

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.

1.1.2 Options

Question 2: Which of the following options are supported by the implementation?

Response

IEC 60559 Floating-Point option	Yes No
IPV6	Yes No
Raw Sockets	Yes No

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.

1.1.3 POSIX.1 Supported Features

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

Where indicated in the following table, select one of the options given (either "Yes" or "Variable"). Select "Variable" if there are system dependent or file system dependent configuration procedures that can remove or modify any or all of these features.

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.
_POSIX2_SYMLINKS	Symbolic links can be created.

If any of the above are Variable, describe in the area below the manner in which variations occur.

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>.

1.1.4 Float, Stdio, and Limit Values

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 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.
AIO_MAX	Maximum number of outstanding asynchronous I/O operations.
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.
DELAYTIMER_MAX	Maximum number of timer expiration overruns.
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.
RE_DUP_MAX	Maximum number of repeated occurrences of a BRE or ERE interval expression.
RTSIG_MAX	Maximum number of realtime signals reserved for application use.
SEM_NSEMS_MAX	Maximum number of semaphores that a process may have.
SEM_VALUE_MAX	The maximum value a semaphore may have.
SIGQUEUE_MAX	Maximum number of pending queued signals.
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.
TIMER_MAX	Maximum number of timers per process.
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 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

For each line in the table below, add the minimum and maximum values for your implementation. These values may be stated to be "Unlimited" if your implementation does not impose a limit. The minimum should be the smallest value that is returned from sysconf(), pathconf(), or fpathconf(), or as defined in <limits.h>. The maximum value should be the largest value that is returned from sysconf(), pathconf(), or fpathconf().

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 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.
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 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.
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 7, Chapter 13, Headers, <stdio.h>.

1.1.5 File Timestamp Resolution

Question 9: What is the resolution of file timestamps in a file system?

Response

If all files on all conforming file systems have the same timestamp resolution, give that value either as 1 second or as the number of nanoseconds returned by pathconf(). If the resolution varies by file system, give the value (as 1 second or the number of nanoseconds) for each conforming file system type supported by the implementation. Do not list non-conforming file system types such as VFAT.

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.

1.1.6 Mathematical Interfaces

Question 10: What format of floating-point numbers is supported by this implementation?

Response

Provide a description of the floating-point format used by your implementation.

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

Provide a list of the floating-point exceptions using the constant names in the <fenv.h> header.

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

Provide a list of the floating-point round modes using the constant names in the <fenv.h> header.

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 No

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().

1.1.7 Data Encryption

Question 14: Are the optional data encryption interfaces provided?

Response

Mark each of the following table entries appropriately. If your implementation is affected by any export restrictions imposed by the US Government, indicate these restrictions in the following area.

Function	Provided
crypt()	Yes No
encrypt()	Yes No
setkey()	Yes No

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 7, Section 2.1.5.2, XSI Option Groups.

1.2 Process Handling

1.2.1 Process Generation

Question 15: Which file types (regular, directory, FIFO, special and so on) are considered to be executable?

Response

Enter the file types that are executable on your implementation in the area below.

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.

1.3 File Handling

1.3.1 Access Control

Question 16: What file access control mechanisms does the implementation provide?

Response

Either indicate that "Standard access control is provided.", that the reader should "Refer to the POSIX Conformance Document", or provide a detailed description of the access control and/or additional or alternate access mechanisms on your implementation.

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 No

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().

1.3.2 Directory Protection

Question 18: When mode bit S_ISVTX is set on a directory, can writable files be removed and renamed within the directory?

Response

If all file types are treated the same, answer "Yes" or "No". If the behavior differs for different file types, specify which file types have a yes or no answer (for example "Yes for non-directory files, no for directories").

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.

1.3.3 Symbolic Links

Question 19: How does link() handle symbolic links?

Response

It creates a new link to the symbolic link itself

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().

1.4 Coded Character Sets

Question 20: What coded character sets are supported by the implementation?

Response

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

Provide the name or description of the underlying codeset, for example ISO 8859-1:1987.

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.

1.5 Pseudo-Terminals

1.5.1 Master close

Question 22: Does closing the master side of a pseudo-terminal flush all queued input and output?

Response

Yes No

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().

1.5.2 Slave 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

Not Applicable - STREAMS-based pseudo-terminals are not supported

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().

1.5.3 Naming Conventions

Question 24: What naming conventions are associated with the master side of pseudo-terminal devices?

Response

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().

1.6 Polling

Question 25: What types of file can be polled?

Response

Update the following list with any additional implementation-specific file types that can be polled.

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().

1.7 Signal Codes

Question 26: Which of the following si_code values may be generated?

Response

If the XSI STREAMS option is not supported, answer N/A (Not Applicable) for the SIGPOLL-related si_code values.

Signal	Code	Generated?
SIGILL	ILL_ILLOPC	Yes No
	ILL_ILLOPN	Yes No
	ILLL_ILLADR	Yes No
	ILL_ILLTRP	Yes No
	ILL_PRVOPC	Yes No
	ILL_PRVREG	Yes No
	ILL_COPROC	Yes No
	ILL_BADSTK	Yes No
SIGFPE	FPE_INTDIV	Yes No
	FPE_INTOVF	Yes No
	FPE_FLTDIV	Yes No
	FPE_FLTOVF	Yes No
	FPE_FLTUND	Yes No
	FPE_FLTRES	Yes No
	FPE_FLTINV	Yes No
	FPE_FLTSUB	Yes No
SIGSEGV	SEGV_MAPERR	Yes No
SIGSEGV	SEGV_ACCERR	Yes No
SIGBUS	BUS_ADRALN	Yes No
	BUS_ADRERR	Yes No
	BUS_OBJERR	Yes No
SIGTRAP	TRAP_BRKPT	Yes No
SIGTRAP	TRAP_TRACE	Yes No
SIGCHLD	CLD_EXITED	Yes No
	CLD_KILLED	Yes No
	CLD_DUMPED	Yes No
	CLD_TRAPPED	Yes No
	CLD_STOPPED	Yes No
	CLD_CONTINUED	Yes No
SIGPOLL	POLL_IN	Yes No N/A
	POLL_OUT	Yes No N/A
	POLL_MSG	Yes No N/A
	POLL_ERR	Yes No N/A
	POLL_PRI	Yes No N/A
	POLL_HUP	Yes No N/A
Any	SI_USER	Yes No
	SI_QUEUE	Yes No
	SI_TIMER	Yes No
	SI_ASYNCIO	Yes No
	SI_MESGQ	Yes 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>.

1.8 Set Process Group ID

Question 27: Does the setpgrp() function create a new session?

Response

Yes No

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().

1.9 Signals Generating a Core File

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	Yes No
SIGFPE	Yes No
SIGILL	Yes No
SIGQUIT	Yes No
SIGSEGV	Yes No
SIGBUS	Yes No
SIGSYS	Yes No
SIGTRAP	Yes No
SIGXCPU	Yes No
SIGXFSZ	Yes 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.

1.10 Sockets

1.10.1 Listen Queues

Question 29: What is the limit the implementation places on the length of a socket's listen queue?

Response

Indicate the implementation's limit on the length of the socket's listen queue, or "None" if no limit is imposed.

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().

1.10.2 Address Families, Socket Types, and Protocols

Question 30: What combinations of address family, socket types, and protocols does the implementation support?

Response

Indicate whether the combinations shown below are supported. (Note that "N/A" equals not applicable).

Address Family	Protocol	Socket Type	Supported?
AF_UNIX	N/A	STREAM	Yes
AF_UNIX	N/A	SEQPACKET	Yes No
AF_UNIX	N/A	DGRAM	Yes No
AF_INET	TCP	STREAM	Yes
AF_INET	UDP	DGRAM	Yes
AF_INET6	TCP	STREAM	Yes No
AF_INET6	UDP	DGRAM	Yes No

If any additional combinations are supported please list them below.

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:

AF_INET, with at least SOCK_STREAM and SOCK_DGRAM socket types
AF_UNIX, with at least the SOCK_STREAM socket type.

Reference

Technical Standard, System Interfaces, Issue 7, Section 2.10, Sockets.

Product Standard, Internationalized System Calls and Libraries Extended V4.

1.10.3 Socket Types

Question 31: What socket types does the implementation support?

Response

List the supported types.

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.

1.11 Threads

1.11.1 Cancellation Points

Question 32: Which functions have cancellation points that occur when a thread is executing?

Response

There are many functions which may have a cancellation point listed in System Interfaces, Section 2.9.5.2. Select those which have cancellation points in your implementation.

Function	Cancellation Point?
access()	Yes No
asctime_r()	Yes No
catclose()	Yes No
catopen()	Yes No
chmod()	Yes No
chown()	Yes No
closedir()	Yes No
closelog()	Yes No
ctermid()	Yes No
ctime_r()	Yes No
dlclose()	Yes No
dlopen()	Yes No
dprintf()	Yes No
endhostent()	Yes No
endnetent()	Yes No
endprotoent()	Yes No
endservent()	Yes No
faccessat()	Yes No
fchmod()	Yes No
fchmodat()	Yes No
fchown()	Yes No
fchownat()	Yes No
fclose()	Yes No
fcntl()	Yes No
fflush()	Yes No
fgetc()	Yes No
fgetpos()	Yes No
fgets()	Yes No
fgetwc()	Yes No
fgetws()	Yes No
fmtmsg()	Yes No
fopen()	Yes No
fpathconf()	Yes No
fprintf()	Yes No
fputc()	Yes No
fputs()	Yes No
fputwc()	Yes No
fputws()	Yes No
fread()	Yes No
freopen()	Yes No
fscanf()	Yes No
fseek()	Yes No
fseeko()	Yes No
fsetpos()	Yes No
fstat()	Yes No
fstatat()	Yes No
ftell()	Yes No
ftello()	Yes No
futimens()	Yes No
fwprintf()	Yes No
fwrite()	Yes No
fwscanf()	Yes No
getaddrinfo()	Yes No
getc()	Yes No
getc_unlocked()	Yes No
getchar()	Yes No
getchar_unlocked()	Yes No
getcwd()	Yes No
getdelim()	Yes No
getgrgid_r()	Yes No
getgrnam_r()	Yes No
gethostid()	Yes No
gethostname()	Yes No
getline()	Yes No
getlogin_r()	Yes No
getnameinfo()	Yes No
getpwnam_r()	Yes No
getpwuid_r()	Yes No
gets()	Yes No
getwc()	Yes No
getwchar()	Yes No
glob()	Yes No
iconv_close()	Yes No
iconv_open()	Yes No
ioctl()	Yes No
link()	Yes No
linkat()	Yes No
lio_listio()	Yes No
localtime_r()	Yes No
lockf()	Yes No
lseek()	Yes No
lstat()	Yes No
mkdir()	Yes No
mkdirat()	Yes No
mkdtemp()	Yes No
mkfifo()	Yes No
mkfifoat()	Yes No
mknod()	Yes No
mknodat()	Yes No
mkstemp()	Yes No
mktime()	Yes No
opendir()	Yes No
openlog()	Yes No
pathconf()	Yes No
perror()	Yes No
popen()	Yes No
posix_fadvise()	Yes No
posix_fallocate()	Yes No
posix_madvise()	Yes No
posix_openpt()	Yes No
posix_spawn()	Yes No
posix_spawnp()	Yes No
posix_typed_mem_open()	Yes No
printf()	Yes No
psiginfo()	Yes No
psignal()	Yes No
pthread_rwlock_rdlock()	Yes No
pthread_rwlock_timedrdlock()	Yes No
pthread_rwlock_timedwrlock()	Yes No
pthread_rwlock_wrlock()	Yes No
putc()	Yes No
putc_unlocked()	Yes No
putchar()	Yes No
putchar_unlocked()	Yes No
puts()	Yes No
putwc()	Yes No
putwchar()	Yes No
readdir_r()	Yes No
readlink()	Yes No
readlinkat()	Yes No
remove()	Yes No
rename()	Yes No
renameat()	Yes No
rewind()	Yes No
rewinddir()	Yes No
scandir()	Yes No
scanf()	Yes No
seekdir()	Yes No
semop()	Yes No
sethostent()	Yes No
setnetent()	Yes No
setprotoent()	Yes No
setservent()	Yes No
sigpause()	Yes No
stat()	Yes No
strerror_l()	Yes No
strerror_r()	Yes No
strftime()	Yes No
strftime_l()	Yes No
syslog()	Yes No
tmpfile()	Yes No
tmpnam()	Yes No
ttyname_r()	Yes No
tzset()	Yes No
ungetc()	Yes No
ungetwc()	Yes No
unlink()	Yes No
unlinkat()	Yes No
utime()	Yes No
utimensat()	Yes No
utimes()	Yes No
vdprintf()	Yes No
vfprintf()	Yes No
vfwprintf()	Yes No
vprintf()	Yes No
vwprintf()	Yes No
wcsftime()	Yes No
wordexp()	Yes No
wprintf()	Yes No
wscanf()	Yes 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.

1.12 C-language Compilation Environment

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 No
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 No
The implementation provides a C-language compilation environment with 32-bit int, and 64-bit long, pointer and off_t types.	Yes No
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 No

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 No
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 No
The implementation provides an execution environment with 32-bit int, and 64-bit long, pointer and off_t types.	Yes 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.	Yes 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>.

1.13 Realtime

1.13.1 Prioritized I/O

Question 35: If the Realtime Option Group is supported, does the implementation support _POSIX_PRIORITIZED_IO?

Response

Not applicable - the Realtime Option Group is not supported.

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 7, Section 2.1.5.2, Realtime

1.13.2 Cancelable Asynchronous I/O Operations

Question 36: What asynchronous I/O operations are cancelable with aio_cancel()?

Response

List the operations that are cancelable in the text area below.

Rationale

The operations which are cancelable are implementation-defined.

Reference

Technical Standard, System Interfaces, Issue 7, Chapter 3, System Interfaces, aio_cancel().

1.14 Realtime Threads

1.14.1 Scheduling Policies

Question 37: If the Realtime Threads Option Group is supported, what scheduling policy is associated with SCHED_OTHER?

Response

If the Realtime Threads option group is supported, describe the scheduling policy provided by the implementation when SCHED_OTHER is requested. If this policy executes identically with SCHED_FIFO or SCHED_RR, this should be indicated. Otherwise a complete description must be provided, including the scheduling parameters used with pthread_getschedparam() and pthread_setschedparam(), or a reference to available system documentation. Otherwise, type "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.

1.14.2 Scheduling Contention Scope

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.
PTHREAD_SCOPE_PROCESS.
PTHREAD_SCOPE_SYSTEM.
Both PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM.

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.

1.14.3 Default 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.
PTHREAD_SCOPE_PROCESS.
PTHREAD_SCOPE_SYSTEM.

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.

2. Appendix

Note to supplier, if more than one page please supply an external html file to The Open Group who will link it into place.

This appendix contains additional, explanatory material that was provided by the vendor.

3. Change History

Date	Name	Comment
New

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.