A conforming implementation shall meet all of the following criteria:
The system shall support all utilities, functions, and facilities defined within IEEE Std 1003.1-2001 that are required for POSIX conformance (see POSIX Conformance). These interfaces shall support the functional behavior described herein.
The system may support one or more options as described under Option Groups. When an implementation claims that an option is supported, all of its constituent parts shall be provided.
The system may support the X/Open System Interface Extension (XSI) as described under XSI Conformance.
The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application).
A conformance document with the following information shall be available for an implementation claiming conformance to IEEE Std 1003.1-2001. The conformance document shall have the same structure as IEEE Std 1003.1-2001, with the information presented in the appropriate sections and subsections. Sections and subsections that consist solely of subordinate section titles, with no other information, are not required. The conformance document shall not contain information about extended facilities or capabilities outside the scope of IEEE Std 1003.1-2001.
The conformance document shall contain a statement that indicates the full name, number, and date of the standard that applies. The conformance document may also list international software standards that are available for use by a Conforming POSIX Application. Applicable characteristics where documentation is required by one of these standards, or by standards of government bodies, may also be included.
The conformance document shall describe the limit values found in the headers <limits.h> and <unistd.h> , stating values, the conditions under which those values may change, and the limits of such variations, if any.
The conformance document shall describe the behavior of the implementation for all implementation-defined features defined in IEEE Std 1003.1-2001. This requirement shall be met by listing these features and providing either a specific reference to the system documentation or providing full syntax and semantics of these features. When the value or behavior in the implementation is designed to be variable or customized on each instantiation of the system, the implementation provider shall document the nature and permissible ranges of this variation.
The conformance document may specify the behavior of the implementation for those features where IEEE Std 1003.1-2001 states that implementations may vary or where features are identified as undefined or unspecified.
The conformance document shall not contain documentation other than that specified in the preceding paragraphs except where such documentation is specifically allowed or required by other provisions of IEEE Std 1003.1-2001.
The phrases "shall document" or "shall be documented" in IEEE Std 1003.1-2001 mean that documentation of the feature shall appear in the conformance document, as described previously, unless there is an explicit reference in the conformance document to show where the information can be found in the system documentation.
The system documentation should also contain the information found in the conformance document.
A conforming implementation shall meet the following criteria for POSIX conformance.
The system shall support all the mandatory functions and headers defined in IEEE Std 1003.1-2001, and shall set the symbolic constant _POSIX_VERSION to the value 200112L.
Although all implementations conforming to IEEE Std 1003.1-2001 support all the features described below, there may be system-dependent or file system-dependent configuration procedures that can remove or modify any or all of these features. Such configurations should not be made if strict compliance is required.
The following symbolic constants shall either be undefined or defined with a value other than -1. If a constant is undefined, an application should use the sysconf(), pathconf(), or fpathconf() functions, or the getconf utility, to determine which features are present on the system at that time or for the particular pathname in question.
_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 to one of its supplementary group IDs.
_POSIX_NO_TRUNC
Pathname components longer than {NAME_MAX} generate an error.
The following symbolic constants shall be defined as follows:
_POSIX_JOB_CONTROL shall have a value greater than zero.
_POSIX_SAVED_IDS shall have a value greater than zero.
_POSIX_VDISABLE shall have a value other than -1.
The system may support one or more options (see Options) denoted by the following symbolic constants:
_POSIX_ADVISORY_INFO
_POSIX_ASYNCHRONOUS_IO
_POSIX_BARRIERS
_POSIX_CLOCK_SELECTION
_POSIX_CPUTIME
_POSIX_FSYNC
_POSIX_IPV6
_POSIX_MAPPED_FILES
_POSIX_MEMLOCK
_POSIX_MEMLOCK_RANGE
_POSIX_MEMORY_PROTECTION
_POSIX_MESSAGE_PASSING
_POSIX_MONOTONIC_CLOCK
_POSIX_PRIORITIZED_IO
_POSIX_PRIORITY_SCHEDULING
_POSIX_RAW_SOCKETS
_POSIX_REALTIME_SIGNALS
_POSIX_SEMAPHORES
_POSIX_SHARED_MEMORY_OBJECTS
_POSIX_SPAWN
_POSIX_SPIN_LOCKS
_POSIX_SPORADIC_SERVER
_POSIX_SYNCHRONIZED_IO
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_CPUTIME
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PRIO_INHERIT
_POSIX_THREAD_PRIO_PROTECT
_POSIX_THREAD_PRIORITY_SCHEDULING
_POSIX_THREAD_PROCESS_SHARED
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREAD_SPORADIC_SERVER
_POSIX_THREADS
_POSIX_TIMEOUTS
_POSIX_TIMERS
_POSIX_TRACE
_POSIX_TRACE_EVENT_FILTER
_POSIX_TRACE_INHERIT
_POSIX_TRACE_LOG
_POSIX_TYPED_MEMORY_OBJECTS
If any of the symbolic constants _POSIX_TRACE_EVENT_FILTER, _POSIX_TRACE_LOG, or _POSIX_TRACE_INHERIT is defined to have a value other than -1, then the symbolic constant _POSIX_TRACE shall also be defined to have a value other than -1.
[XSI] The system may support the XSI extensions (see XSI Option Groups) denoted by the following symbolic constants:
_XOPEN_CRYPT
_XOPEN_LEGACY
_XOPEN_REALTIME
_XOPEN_REALTIME_THREADS
_XOPEN_UNIX
The system shall provide all the mandatory utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 with all the functional behavior described therein.
The system shall support the Large File capabilities described in the Shell and Utilities volume of IEEE Std 1003.1-2001.
The system may support one or more options (see Options) denoted by the following symbolic constants. (The literal names below apply to the getconf utility.)
POSIX2_C_DEV
POSIX2_CHAR_TERM
POSIX2_FORT_DEV
POSIX2_FORT_RUN
POSIX2_LOCALEDEF
POSIX2_PBS
POSIX2_PBS_ACCOUNTING
POSIX2_PBS_LOCATE
POSIX2_PBS_MESSAGE
POSIX2_PBS_TRACK
POSIX2_SW_DEV
POSIX2_UPE
The system may support the XSI extensions (see XSI Conformance).
Additional language bindings and development utility options may be provided in other related standards or in a future version of IEEE Std 1003.1-2001. In the former case, additional symbolic constants of the same general form as shown in this subsection should be defined by the related standard document and made available to the application without requiring IEEE Std 1003.1-2001 to be updated.
[XSI] This section describes the criteria for implementations conforming to the XSI extension (see XSI). This functionality is dependent on the support of the XSI extension (and the rest of this section is not further marked).
IEEE Std 1003.1-2001 describes utilities, functions, and facilities offered to application programs by the X/Open System Interface (XSI). An XSI-conforming implementation shall meet the criteria for POSIX conformance and the following requirements.
The system shall support all the functions and headers defined in IEEE Std 1003.1-2001 as part of the XSI extension denoted by the symbolic constant _XOPEN_UNIX and any extensions marked with the XSI extension marking (see Codes).
The system shall support the mmap(), munmap(), and msync() functions.
The system shall support the following options defined within IEEE Std 1003.1-2001 (see Options):
_POSIX_FSYNC
_POSIX_MAPPED_FILES
_POSIX_MEMORY_PROTECTION
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PROCESS_SHARED
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREADS
The system may support the following XSI Option Groups (see XSI Option Groups) defined within IEEE Std 1003.1-2001:
Encryption
Realtime
Advanced Realtime
Realtime Threads
Advanced Realtime Threads
Tracing
XSI STREAMS
Legacy
The system shall support all the utilities defined in the Shell and Utilities volume of IEEE Std 1003.1-2001 as part of the XSI extension denoted by the XSI marking in the SYNOPSIS section, and any extensions marked with the XSI extension marking (see Codes) within the text.
The system shall support the User Portability Utilities option.
The system shall support creation of locales (see Locale).
The C-language Development utility c99 shall be supported.
The XSI Development Utilities option may be supported. It consists of the following software development utilities:
Within the utilities that are provided, functionality marked by the code OF (see Codes) need not be provided.
An Option Group is a group of related functions or options defined within the System Interfaces volume of IEEE Std 1003.1-2001.
If an implementation supports an Option Group, then the system shall support the functional behavior described herein.
If an implementation does not support an Option Group, then the system need not support the functional behavior described herein.
Profiling standards supporting functional requirements less than that required in IEEE Std 1003.1-2001 may subset both mandatory and optional functionality required for POSIX Conformance (see POSIX Conformance) or XSI Conformance (see XSI Conformance). Such profiles shall organize the subsets into Subprofiling Option Groups.
The Rationale (Informative) volume of IEEE Std 1003.1-2001, Appendix E, Subprofiling Considerations (Informative) describes a representative set of such Subprofiling Option Groups for use by profiles applicable to specialized realtime systems. IEEE Std 1003.1-2001 does not require that the presence of Subprofiling Option Groups be testable at compile-time (as symbols defined in any header) or at runtime (via sysconf() or getconf).
A Subprofiling Option Group may provide basic system functionality that other Subprofiling Option Groups and other options depend upon.1 If a profile of IEEE Std 1003.1-2001 does not require an implementation to provide a Subprofiling Option Group that provides features utilized by a required Subprofiling Option Group (or option),2 the profile shall specify3 all of the following:
Restricted or altered behavior of interfaces defined in IEEE Std 1003.1-2001 that may differ on an implementation of the profile
Additional behaviors that may produce undefined or unspecified results
Additional implementation-defined behavior that implementations shall be required to document in the profile's conformance document
if any of the above is a result of the profile not requiring an interface required by IEEE Std 1003.1-2001.
The following additional rules shall apply to all profiles of IEEE Std 1003.1-2001:
Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001 (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001).
Profiles are permitted to add additional requirements to the limits defined in <limits.h> and <stdint.h>, subject to the following:
For the limits in <limits.h> and <stdint.h>:
If the limit is specified as having a fixed value, it shall not be changed by a profile.
If a limit is specified as having a minimum or maximum acceptable value, it may be changed by a profile as follows:
A profile may increase a minimum acceptable value, but shall not make a minimum acceptable value smaller.
A profile may reduce a maximum acceptable value, but shall not make a maximum acceptable value larger.
A profile shall not change a limit specified as having a minimum or maximum value into a limit specified as having a fixed value.
A profile shall not create new limits.
Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile.
[XSI] This section describes Option Groups to support the definition of XSI conformance within the System Interfaces volume of IEEE Std 1003.1-2001. This functionality is dependent on the support of the XSI extension (and the rest of this section is not further marked).
The following Option Groups are defined.
The Encryption Option Group is denoted by the symbolic constant _XOPEN_CRYPT. It includes the following functions:
crypt(), encrypt(), setkey()
These functions are marked CRYPT.
Due to export restrictions on the decoding algorithm in some countries, implementations may be restricted in making these functions available. All the functions in the Encryption Option Group may therefore return [ENOSYS] or, alternatively, encrypt() shall return [ENOSYS] for the decryption operation.
An implementation that claims conformance to this Option Group shall set _XOPEN_CRYPT to a value other than -1.
The Realtime Option Group is denoted by the symbolic constant _XOPEN_REALTIME.
This Option Group includes a set of realtime functions drawn from options within IEEE Std 1003.1-2001 (see Options).
Where entire functions are included in the Option Group, the NAME section is marked with REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std 1003.1-2001.
An implementation that claims conformance to this Option Group shall set _XOPEN_REALTIME to a value other than -1.
This Option Group consists of the set of the following options from within IEEE Std 1003.1-2001 (see Options):
_POSIX_ASYNCHRONOUS_IO _POSIX_FSYNC _POSIX_MAPPED_FILES _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MEMORY_PROTECTION _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS
If the symbolic constant _XOPEN_REALTIME is defined to have a value other than -1, then the following symbolic constants shall be defined by the implementation to have the value 200112L:
_POSIX_ASYNCHRONOUS_IO _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MESSAGE_PASSING _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS
The functionality associated with _POSIX_MAPPED_FILES, _POSIX_MEMORY_PROTECTION, and _POSIX_FSYNC is always supported on XSI-conformant systems.
Support of _POSIX_PRIORITIZED_IO on XSI-conformant systems is optional. If this functionality is supported, then _POSIX_PRIORITIZED_IO shall be set to a value other than -1. Otherwise, it shall be undefined.
If _POSIX_PRIORITIZED_IO is supported, then asynchronous I/O operations performed by aio_read(), aio_write(), and lio_listio() shall be submitted at a priority equal to the scheduling priority equal to a base scheduling priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is not supported, then the base scheduling priority is that of the calling process; otherwise, the base scheduling priority is that of the calling thread. The implementation shall also document for which files I/O prioritization is supported.
An implementation that claims conformance to this Option Group shall also support the Realtime Option Group.
Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std 1003.1-2001.
This Option Group consists of the set of the following options from within IEEE Std 1003.1-2001 (see Options):
_POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS
If the implementation supports the Advanced Realtime Option Group, then the following symbolic constants shall be defined by the implementation to have the value 200112L:
_POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS
If the symbolic constant _POSIX_SPORADIC_SERVER is defined, then the symbolic constant _POSIX_PRIORITY_SCHEDULING shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_MONOTONIC_CLOCK is defined, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_CLOCK_SELECTION is defined, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L.
The Realtime Threads Option Group is denoted by the symbolic constant _XOPEN_REALTIME_THREADS.
This Option Group consists of the set of the following options from within IEEE Std 1003.1-2001 (see Options):
_POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING
Where applicable, whole pages are marked REALTIME THREADS, together with the appropriate option margin legend for the SYNOPSIS section (see Codes).
An implementation that claims conformance to this Option Group shall set _XOPEN_REALTIME_THREADS to a value other than -1.
If the symbol _XOPEN_REALTIME_THREADS is defined to have a value other than -1, then the following options shall also be defined by the implementation to have the value 200112L:
_POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING
An implementation that claims conformance to this Option Group shall also support the Realtime Threads Option Group.
Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME THREADS. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std 1003.1-2001.
This Option Group consists of the set of the following options from within IEEE Std 1003.1-2001 (see Options):
_POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER
If the symbolic constant _POSIX_THREAD_SPORADIC_SERVER is defined to have the value 200112L, then the symbolic constant _POSIX_THREAD_PRIORITY_SCHEDULING shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_THREAD_CPUTIME is defined to have the value 200112L, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_BARRIERS is defined to have the value 200112L, then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined by the implementation to have the value 200112L.
If the symbolic constant _POSIX_SPIN_LOCKS is defined to have the value 200112L, then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined by the implementation to have the value 200112L.
If the implementation supports the Advanced Realtime Threads Option Group, then the following symbolic constants shall be defined by the implementation to have the value 200112L:
_POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER
This Option Group includes a set of tracing functions drawn from options within IEEE Std 1003.1-2001 (see Options).
Where entire functions are included in the Option Group, the NAME section is marked with TRACING. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std 1003.1-2001.
This Option Group consists of the set of the following options from within IEEE Std 1003.1-2001 (see Options):
_POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT
If the implementation supports the Tracing Option Group, then the following symbolic constants shall be defined by the implementation to have the value 200112L:
_POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT
The XSI STREAMS Option Group is denoted by the symbolic constant _XOPEN_STREAMS.
This Option Group includes functionality related to STREAMS, a uniform mechanism for implementing networking services and other character-based I/O as described in the System Interfaces volume of IEEE Std 1003.1-2001, Section 2.6, STREAMS.
It includes the following functions:
fattach(), fdetach(), getmsg(), getpmsg(), ioctl(), isastream(), putmsg(), putpmsg()
and the <stropts.h> header.
Where applicable, whole pages are marked STREAMS, together with the appropriate option margin legend for the SYNOPSIS section (see Codes). Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std 1003.1-2001.
An implementation that claims conformance to this Option Group shall set _XOPEN_STREAMS to a value other than -1.
The Legacy Option Group is denoted by the symbolic constant _XOPEN_LEGACY.
The Legacy Option Group includes the functions and headers which were mandatory in previous versions of IEEE Std 1003.1-2001 but are optional in this version.
These functions and headers are retained in IEEE Std 1003.1-2001 because of their widespread use. Application writers should not rely on the existence of these functions or headers in new applications, but should follow the migration path detailed in the APPLICATION USAGE sections of the relevant pages.
Various factors may have contributed to the decision to mark a function or header LEGACY. In all cases, the specific reasons for the withdrawal of a function or header are documented on the relevant pages.
Once a function or header is marked LEGACY, no modifications are made to the specifications of such functions or headers other than to the APPLICATION USAGE sections of the relevant pages.
The functions and headers which form this Option Group are as follows:
bcmp(), bcopy(), bzero(), ecvt(), fcvt(), ftime(), gcvt(), getwd(), index(), mktemp(), rindex(), utimes(), wcswcs()
An implementation that claims conformance to this Option Group shall set _XOPEN_LEGACY to a value other than -1.
The symbolic constants defined in <unistd.h>, Constants for Options and Option Groups reflect implementation options for IEEE Std 1003.1-2001. These symbols can be used by the application to determine which optional facilities are present on the implementation. The sysconf() function defined in the System Interfaces volume of IEEE Std 1003.1-2001 or the getconf utility defined in the Shell and Utilities volume of IEEE Std 1003.1-2001 can be used to retrieve the value of each symbol on each specific implementation to determine whether the option is supported.
Where an option is not supported, the associated utilities, functions, or facilities need not be present.
Margin codes are defined for each option (see Codes).
Refer to <unistd.h>, Constants for Options and Option Groups for the list of options.
Each of these symbols shall be considered valid names by the implementation. Refer to <unistd.h>, Constants for Options and Option Groups .
The literal names shown below apply only to the getconf utility.
The utilities in the C-Language Development Utilities option are used for the development of C-language applications, including compilation or translation of C source code and complex program generators for simple lexical tasks and processing of context-free grammars.
The utilities listed below may be provided by a conforming system; however, any system claiming conformance to the C-Language Development Utilities option shall provide all of the utilities listed.
c99 lex yacc
Where applicable, the dependency is noted within the description of the utility.
This option applies only to systems supporting the User Portability Utilities option. If supported, then the system supports at least one terminal type capable of all operations described in IEEE Std 1003.1-2001; see Output Devices and Terminal Types.
The fort77 FORTRAN compiler is the only utility in the FORTRAN Development Utilities option. This is used for the development of FORTRAN language applications, including compilation or translation of FORTRAN source code.
The fort77 utility may be provided by a conforming system; however, any system claiming conformance to the FORTRAN Development Utilities option shall provide the fort77 utility.
The asa utility is the only utility in the FORTRAN Runtime Utilities option.
The asa utility may be provided by a conforming system; however, any system claiming conformance to the FORTRAN Runtime Utilities option shall provide the asa utility.
If supported, the system supports the creation of locales as described in the localedef utility.
The localedef utility may be provided by a conforming system; however, any system claiming conformance to the Locale Creation Utilities option shall provide the localedef utility.
The utilities in the Software Development Utilities option are used for the development of applications, including compilation or translation of source code, the creation and maintenance of library archives, and the maintenance of groups of inter-dependent programs.
The utilities listed below may be provided by the conforming system; however, any system claiming conformance to the Software Development Utilities option shall provide all of the utilities listed here.
ar make nm strip
The utilities in the User Portability Utilities option shall be implemented on all systems that claim conformance to this option. Certain utilities are noted as having features that cannot be implemented on all terminal types; if the POSIX2_CHAR_TERM option is supported, the system shall support all such features on at least one terminal type; see Output Devices and Terminal Types.
Some of the utilities are required only on systems that also support the Software Development Utilities option, or the character-at-a-time terminal option (see Output Devices and Terminal Types); such utilities have this noted in their DESCRIPTION sections. All of the other utilities listed are required only on systems that claim conformance to the User Portability Utilities option.
All applications claiming conformance to IEEE Std 1003.1-2001 shall use only language-dependent services for the C programming language described in Language-Dependent Services for the C Programming Language , shall use only the utilities and facilities defined in the Shell and Utilities volume of IEEE Std 1003.1-2001, and shall fall within one of the following categories.
A Strictly Conforming POSIX Application is an application that requires only the facilities described in IEEE Std 1003.1-2001. Such an application:
Shall accept any implementation behavior that results from actions it takes in areas described in IEEE Std 1003.1-2001 as implementation-defined or unspecified, or where IEEE Std 1003.1-2001 indicates that implementations may vary
Shall not perform any actions that are described as producing undefined results
For symbolic constants, shall accept any value in the range permitted by IEEE Std 1003.1-2001, but shall not rely on any value in the range being greater than the minimums listed or being less than the maximums listed in IEEE Std 1003.1-2001
Shall not use facilities designated as obsolescent
Is required to tolerate and permitted to adapt to the presence or absence of optional facilities whose availability is indicated by POSIX Conformance
For the C programming language, shall not produce any output dependent on any behavior described in the ISO/IEC 9899:1999 standard as unspecified, undefined, or implementation-defined, unless the System Interfaces volume of IEEE Std 1003.1-2001 specifies the behavior
For the C programming language, shall not exceed any minimum implementation limit defined in the ISO/IEC 9899:1999 standard, unless the System Interfaces volume of IEEE Std 1003.1-2001 specifies a higher minimum implementation limit
For the C programming language, shall define _POSIX_C_SOURCE to be 200112L before any header is included
Within IEEE Std 1003.1-2001, any restrictions placed upon a Conforming POSIX Application shall restrict a Strictly Conforming POSIX Application.
An ISO/IEC Conforming POSIX Application is an application that uses only the facilities described in IEEE Std 1003.1-2001 and approved Conforming Language bindings for any ISO or IEC standard. Such an application shall include a statement of conformance that documents all options and limit dependencies, and all other ISO or IEC standards used.
A <National Body> Conforming POSIX Application differs from an ISO/IEC Conforming POSIX Application in that it also may use specific standards of a single ISO/IEC member body referred to here as <National Body>. Such an application shall include a statement of conformance that documents all options and limit dependencies, and all other <National Body> standards used.
A Conforming POSIX Application Using Extensions is an application that differs from a Conforming POSIX Application only in that it uses non-standard facilities that are consistent with IEEE Std 1003.1-2001. Such an application shall fully document its requirements for these extended facilities, in addition to the documentation required of a Conforming POSIX Application. A Conforming POSIX Application Using Extensions shall be either an ISO/IEC Conforming POSIX Application Using Extensions or a <National Body> Conforming POSIX Application Using Extensions (see ISO/IEC Conforming POSIX Application and <National Body> Conforming POSIX Application).
A Strictly Conforming XSI Application is an application that requires only the facilities described in IEEE Std 1003.1-2001. Such an application:
Shall accept any implementation behavior that results from actions it takes in areas described in IEEE Std 1003.1-2001 as implementation-defined or unspecified, or where IEEE Std 1003.1-2001 indicates that implementations may vary
Shall not perform any actions that are described as producing undefined results
For symbolic constants, shall accept any value in the range permitted by IEEE Std 1003.1-2001, but shall not rely on any value in the range being greater than the minimums listed or being less than the maximums listed in IEEE Std 1003.1-2001
Shall not use facilities designated as obsolescent
Is required to tolerate and permitted to adapt to the presence or absence of optional facilities whose availability is indicated by XSI Conformance
For the C programming language, shall not produce any output dependent on any behavior described in the ISO C standard as unspecified, undefined, or implementation-defined, unless the System Interfaces volume of IEEE Std 1003.1-2001 specifies the behavior
For the C programming language, shall not exceed any minimum implementation limit defined in the ISO C standard, unless the System Interfaces volume of IEEE Std 1003.1-2001 specifies a higher minimum implementation limit
For the C programming language, shall define _XOPEN_SOURCE to be 600 before any header is included
Within IEEE Std 1003.1-2001, any restrictions placed upon a Conforming POSIX Application shall restrict a Strictly Conforming XSI Application.
A Conforming XSI Application Using Extensions is an application that differs from a Strictly Conforming XSI Application only in that it uses non-standard facilities that are consistent with IEEE Std 1003.1-2001. Such an application shall fully document its requirements for these extended facilities, in addition to the documentation required of a Strictly Conforming XSI Application.
Implementors seeking to claim conformance using the ISO C standard shall claim POSIX conformance as described in POSIX Conformance.
IEEE Std 1003.1-2001 is currently specified in terms of the shell command language and ISO C. Bindings to other programming languages are being developed.
If conformance to IEEE Std 1003.1-2001 is claimed for implementation of any programming language, the implementation of that language shall support the use of external symbols distinct to at least 31 bytes in length in the source program text. (That is, identifiers that differ at or before the thirty-first byte shall be distinct.) If a national or international standard governing a language defines a maximum length that is less than this value, the language-defined maximum shall be supported. External symbols that differ only by case shall be distinct when the character set in use distinguishes uppercase and lowercase characters and the language permits (or requires) uppercase and lowercase characters to be distinct in external symbols.