Conformance

Implementation Conformance

Requirements

A conforming implementation shall meet all of the following criteria:

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

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

3. The system may support the X/Open System Interface Extension (XSI) as described under XSI Conformance .

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

Documentation

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.

POSIX Conformance

A conforming implementation shall meet the following criteria for POSIX conformance.

POSIX System Interfaces

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

  Note:

  The symbols above represent historical options that are no longer allowed as options, but are retained here for backwards-compatibility of applications.

• 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

POSIX Shell and Utilities

• 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 Conformance

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

XSI System Interfaces

• 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

XSI Shell and Utilities Conformance

• 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:

  admin cflow ctags cxref

  delta get m4 nm

  prs rmdel sact sccs

  unget val what

• Within the utilities that are provided, functionality marked by the code OF (see Codes ) need not be provided.

Option Groups

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.

Subprofiling Considerations

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.¹ 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),² the profile shall specify³ 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 Option Groups

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

Encryption

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.

Realtime

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 of the process minus aiocbp->aio_reqprio. The implementation shall also document for which files I/O prioritization is supported.

Advanced Realtime

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.

Realtime Threads

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

Advanced Realtime Threads

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

Tracing

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

XSI STREAMS

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.

Legacy

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.

Options

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

System Interfaces

Refer to <unistd.h>, Constants for Options and Option Groups for the list of options.

Shell and Utilities

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.

POSIX2_C_DEV

^[CD]
The system supports the C-Language Development Utilities option.

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

POSIX2_CHAR_TERM

The system supports the Terminal Characteristics option. This value need not be present on a system not supporting the User Portability Utilities option.

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 .

POSIX2_FORT_DEV

^[FD]
The system supports the FORTRAN Development Utilities option.

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.

POSIX2_FORT_RUN

^[FR]
The system supports the FORTRAN Runtime Utilities option.

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.

POSIX2_LOCALEDEF

The system supports the Locale Creation Utilities option.

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.

POSIX2_PBS

^[BE]
The system supports the Batch Environment Services and Utilities option (see the Shell and Utilities volume of IEEE Std 1003.1-2001, Chapter 3, Batch Environment Services).

Note:

The Batch Environment Services and Utilities option is a combination of mandatory and optional batch services and utilities. The POSIX_PBS symbolic constant implies the system supports all the mandatory batch services and utilities.

POSIX2_PBS_ACCOUNTING

The system supports the Batch Accounting option.

POSIX2_PBS_CHECKPOINT

The system supports the Batch Checkpoint/Restart option.

POSIX2_PBS_LOCATE

The system supports the Locate Batch Job Request option.

POSIX2_PBS_MESSAGE

The system supports the Batch Job Message Request option.

POSIX2_PBS_TRACK

The system supports the Track Batch Job Request option.

POSIX2_SW_DEV

^[SD]
The system supports the Software Development Utilities option.

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

POSIX2_UPE

^[UP]
The system supports the User Portability Utilities option.

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.

alias at batch bg crontab split ctags df du ex

expand fc fg file jobs man mesg more newgrp nice

nm patch ps renice split strings tabs talk time tput

unalias unexpand uudecode uuencode vi who write

Application Conformance

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.

Strictly Conforming POSIX Application

A Strictly Conforming POSIX Application is an application that requires only the facilities described in IEEE Std 1003.1-2001. Such an application:

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

2. Shall not perform any actions that are described as producing undefined results

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

4. Shall not use facilities designated as obsolescent

5. Is required to tolerate and permitted to adapt to the presence or absence of optional facilities whose availability is indicated by POSIX Conformance

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

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

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

Conforming POSIX Application

ISO/IEC 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.

<National Body> Conforming POSIX Application

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.

Conforming POSIX Application Using Extensions

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

Strictly Conforming XSI Application

A Strictly Conforming XSI Application is an application that requires only the facilities described in IEEE Std 1003.1-2001. Such an application:

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

2. Shall not perform any actions that are described as producing undefined results

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

4. Shall not use facilities designated as obsolescent

5. Is required to tolerate and permitted to adapt to the presence or absence of optional facilities whose availability is indicated by XSI Conformance

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

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

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

Conforming XSI Application Using Extensions

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.

Language-Dependent Services for the C Programming Language

Implementors seeking to claim conformance using the ISO C standard shall claim POSIX conformance as described in POSIX Conformance .

Other Language-Related Specifications

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.

Footnotes

1.

As an example, the File System profiling option group provides underlying support for pathname resolution and file creation which are needed by any interface in IEEE Std 1003.1-2001 that parses a path argument. If a profile requires support for the Device Input and Output profiling option group but does not require support for the File System profiling option group, the profile must specify how pathname resolution is to behave in that profile, how the O_CREAT flag to open() is to be handled (and the use of the character 'a' in the mode argument of fopen() when a filename argument names a file that does not exist), and specify lots of other details.

2.

As an example, IEEE Std 1003.1-2001 requires that implementations claiming to support the Range Memory Locking option also support the Process Memory Locking option. A profile could require that the Range Memory Locking option had to be supplied without requiring that the Process Memory Locking option be supplied as long as the profile specifies everything an application writer or system implementor would have to know to build an application or implementation conforming to the profile.

3.

Note that the profile could just specify that any use of the features not specified by the profile would produce undefined or unspecified results.