The Open Group Base Specifications Issue 7, 2018 edition
IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)
Copyright © 2001-2018 IEEE and The Open Group

A. Rationale for Base Definitions

A.1 Introduction

A.1.1 Scope

POSIX.1-2017 is one of a family of standards known as POSIX. The family of standards extends to many topics; POSIX.1 consists of both operating system interfaces and shell and utilities. POSIX.1-2017 is technically identical to The Open Group Base Specifications, Issue 7.

Scope of POSIX.1-2017

The (paraphrased) goals of this development were to revise the single document that is ISO/IEC 9945:2003 Parts 1 through 4, IEEE Std 1003.1, 2004 Edition, and the appropriate parts of The Open Group Single UNIX Specification, Version 3. This work has been undertaken by the Austin Group, a joint working group of IEEE, The Open Group, and ISO/IEC JTC 1/SC 22.

The following are the base documents in this version:

This version has addressed the following areas:

The following were requirements on POSIX.1-2017:

POSIX.1 and the ISO C Standard

The standard developers believed it essential for a programmer to have a single complete reference place, but recognized that deference to the formal standard has to be addressed for the duplicate interface definitions between the ISO C standard and POSIX.1-2017.

Where an interface has a version in the ISO C standard, the DESCRIPTION section describes the relationship to the ISO C standard and markings are included as appropriate to show where the ISO C standard has been extended in the text.

A block of text is included at the start of each affected reference page stating whether the page is aligned with the ISO C standard or extended. Each page has been parsed for additions beyond the ISO C standard (that is, including both POSIX and UNIX extensions), and these extensions are marked as CX extensions (for C extensions).

FIPS Requirements

The Federal Information Processing Standards (FIPS) are a series of US government procurement standards managed and maintained on behalf of the US Department of Commerce by the National Institute of Standards and Technology (NIST).

The following restrictions were integrated into IEEE Std 1003.1-2001. They originally came from FIPS 151-2 which was withdrawn by NIST on February 25 2000.

A.1.2 Conformance

See Conformance.

A.1.3 Normative References

There is no additional rationale provided for this section.

A.1.4 Change History

For Issue 7 onwards, in references to Technical Corrigenda, the original Austin Group defect report numbers that gave rise to the change are included in square brackets after the change number from the Technical Corrigendum. For more information on Austin Group defect reports see

A.1.5 Terminology

The meanings specified in POSIX.1-2017 for the words shall, should, and may are mandated by ISO/IEC directives.

In the Rationale (Informative) volume of POSIX.1-2017, the words shall, should, and may are sometimes used to illustrate similar usages in POSIX.1-2017. However, the rationale itself does not specify anything regarding implementations or applications.

conformance document

As a practical matter, the conformance document is effectively part of the system documentation. Conformance documents are distinguished by POSIX.1-2017 so that they can be referred to distinctly.


This definition is analogous to that of the ISO C standard and, together with "undefined" and "unspecified", provides a range of specification of freedom allowed to the interface implementor.


The use of may has been limited as much as possible, due both to confusion stemming from its ordinary English meaning and to objections regarding the desirability of having as few options as possible and those as clearly specified as possible.

The usage of can and may were selected to contrast optional application behavior (can) against optional implementation behavior (may).


Declarative sentences are sometimes used in POSIX.1-2017 as if they included the word shall, and facilities thus specified are no less required. For example, the two statements:

  1. The foo() function shall return zero.

  2. The foo() function returns zero.

are meant to be exactly equivalent.


In POSIX.1-2017, the word should does not usually apply to the implementation, but rather to the application. Thus, the important words regarding implementations are shall, which indicates requirements, and may, which indicates options.


The term "obsolescent" means "do not use this feature in new applications". A feature noted as obsolescent is supported by all implementations, but may be removed in a future version; new applications should not use these features. The obsolescence concept is not an ideal solution, but was used as a method of increasing consensus: many more objections would be heard from the user community if some of these historical features were suddenly removed without the grace period obsolescence implies. The phrase "may be removed in a future version" implies that the result of that consideration might in fact keep those features indefinitely if the predominance of applications do not migrate away from them quickly.


The term "legacy" was included in earlier versions of this standard but is no longer used in the current version.

system documentation

The system documentation should normally describe the whole of the implementation, including any extensions provided by the implementation. Such documents normally contain information at least as detailed as the specifications in POSIX.1-2017. Few requirements are made on the system documentation, but the term is needed to avoid a dangling pointer where the conformance document is permitted to point to the system documentation.


See implementation-defined.


See implementation-defined.

The definitions for "unspecified" and "undefined" appear nearly identical at first examination, but are not. The term "unspecified" means that a conforming application may deal with the unspecified behavior, and it should not care what the outcome is. The term "undefined" says that a conforming application should not do it because no definition is provided for what it does (and implicitly it would care what the outcome was if it tried it). It is important to remember, however, that if the syntax permits the statement at all, it must have some outcome in a real implementation.

Thus, the terms "undefined" and "unspecified" apply to the way the application should think about the feature. In terms of the implementation, it is always "defined''-there is always some result, even if it is an error. The implementation is free to choose the behavior it prefers.

This also implies that an implementation, or another standard, could specify or define the result in a useful fashion. The terms apply to POSIX.1-2017 specifically.

The term "implementation-defined" implies requirements for documentation that are not required for "undefined" (or "unspecified"). Where there is no need for a conforming program to know the definition, the term "undefined" is used, even though "implementation-defined" could also have been used in this context. There could be a fourth term, specifying "this standard does not say what this does; it is acceptable to define it in an implementation, but it does not need to be documented", and undefined would then be used very rarely for the few things for which any definition is not useful. In particular, implementation-defined is used where it is believed that certain classes of application will need to know such details to determine whether the application can be successfully ported to the implementation. Such applications are not always strictly portable, but nevertheless are common and useful; often the requirements met by the application cannot be met without dealing with the issues implied by "implementation-defined". In some places the text refers to facilities supplied by the implementation that are outside the standard as implementation-supplied or implementation-provided. This is not intended to imply a requirement for documentation. If it were, the term "implementation-defined" would have been used.

In many places POSIX.1-2017 is silent about the behavior of some possible construct. For example, a variable may be defined for a specified range of values and behaviors are described for those values; nothing is said about what happens if the variable has any other value. That kind of silence can imply an error in the standard, but it may also imply that the standard was intentionally silent and that any behavior is permitted. There is a natural tendency to infer that if the standard is silent, a behavior is prohibited. That is not the intent. Silence is intended to be equivalent to the term "unspecified".

Three terms used within POSIX.1-2017 overlap in meaning: "macro", "symbolic name", and "symbolic constant".


This usually describes a C preprocessor symbol, the result of the #define operator, with or without an argument. It may also be used to describe similar mechanisms in editors and text processors.

symbolic name

In earlier versions of this standard this was also sometimes used to refer to a C preprocessor symbol (without arguments), but the intention is for all such uses to have been removed. It is now mainly used to refer to the names for characters in character sets, but is sometimes used to refer to host names and even filenames.

symbolic constant

This also refers to a C preprocessor symbol, with specific associated requirements. See the definition in Symbolic Constant.

A.1.6 Definitions and Concepts

There is no additional rationale provided for this section.

A.1.7 Portability

To aid the identification of options within POSIX.1-2017, a notation consisting of margin codes and shading is used. This is based on the notation used in earlier versions of The Open Group Base specifications.

The benefit of this approach is a reduction in the number of if statements within the running text, that makes the text easier to read, and also an identification to the programmer that they need to ensure that their target platforms support the underlying options. For example, if functionality is marked with RPP in the margin, it will be available on all systems supporting the Robust Mutex Priority Protection option, but may not be available on some others.


This section includes codes for options defined in XBD Options, and the following additional codes for other purposes:

This margin code is used to denote extensions beyond the ISO C standard. For interfaces that are duplicated between POSIX.1-2017 and the ISO C standard, a CX introduction block describes the nature of the duplication, with any extensions appropriately CX marked and shaded.

Where an interface is added to an ISO C standard header, within the header the interface has an appropriate margin marker and shading (for example, CX, XSI, TSF, and so on) and the same marking appears on the reference page in the SYNOPSIS section. This enables a programmer to easily identify that the interface is extending an ISO C standard header.

MX and MXX
These two margin codes both relate to the IEC 60559 Floating-Point option. The MX code denotes functionality that is mandated by the ISO C standard for IEC 60559 implementations; the MXX code denotes IEC 60559 functionality that is an extension to the ISO C standard.
This margin code is used to denote obsolescent behavior and thus flag a possible future applications portability warning.
The Single UNIX Specification has historically tried to reduce the number of headers an application has had to include when using a particular interface. Sometimes this was fewer than the base standard, and hence a notation is used to flag which headers are optional if you are using a system supporting the XSI option.

POSIX.1-2008, Technical Corrigendum 2, XBD/TC2-2008/0001 [591] is applied.

Margin Code Notation

Since some features may depend on one or more options, or require more than one option, a notation is used. Where a feature requires support of a single option, a single margin code will occur in the margin. If it depends on two options and both are required, then the codes will appear with a <space> separator. If either of two options are required, then a logical OR is denoted using the '|' symbol. If more than two codes are used, a special notation is used.


return to top of page

UNIX ® is a registered Trademark of The Open Group.
POSIX ™ is a Trademark of The IEEE.
Copyright © 2001-2018 IEEE and The Open Group, All Rights Reserved
[ Main Index | XBD | XSH | XCU | XRAT ]