POSIX.1-2008 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-2008 is technically identical to The Open Group Base Specifications, Issue 7.
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:
IEEE Std 1003.1, 2004 Edition
ISO/IEC 9899:1999, Programming Languages - C, including ISO/IEC 9899:1999/Cor.1:2001(E), ISO/IEC 9899:1999/Cor.2:2004(E), and ISO/IEC 9899:1999/Cor.3
The Open Group Extended API Sets, Parts 1 through 4
This version has addressed the following areas:
Issues raised by Austin Group defect reports, IEEE Interpretations against IEEE Std 1003.1, and ISO/IEC defect reports against ISO/IEC 9945
The repository of interpretations can be accessed at www.opengroup.org/austin/interps.
Issues raised in corrigenda for The Open Group Technical Standards and working group resolutions from The Open Group
Issues arising from ISO TR 24715:2006, Conflicts between POSIX and the LSB
This is a Type 3 informative technical report highlighting differences between the LSB 3.1 and the 2004 Edition of this standard.
Changes to make the text self-consistent with the additional material merged
The new material merged has come from the The Open Group Extended API Sets, Parts 1 through 4. A list of the new interfaces is included in Change History.
Features, marked legacy or obsolescent in the base documents, have been considered for removal in this version
See Change History and Change History.
A review and reorganization of the options within the standard
This has included marking the following options obsolescent:
Batch Environment Services and Utilities
Tracing
XSI STREAMS
The UUCP Utilities option is a new option for this version.
Functionality from the following former options is now mandatory in this version:
|
AIO |
_POSIX_ASYNCHRONOUS_IO (Asynchronous Input and Output) |
|
BAR |
_POSIX_BARRIERS (Barriers) |
|
CS |
_POSIX_CLOCK_SELECTION (Clock Selection) |
|
MF |
_POSIX_MAPPED_FILES (Memory Mapped Files) |
|
MPR |
_POSIX_MEMORY_PROTECTION (Memory Protection) |
|
RTS |
_POSIX_REALTIME_SIGNALS (Realtime Signals Extension) |
|
RWL |
_POSIX_READER_WRITER_LOCKS (Read-Write Locks) |
|
SEM |
_POSIX_SEMAPHORES (Semaphores) |
|
SPI |
_POSIX_SPIN_LOCKS (Spin Locks) |
|
THR |
_POSIX_THREADS (Threads) |
|
TMO |
_POSIX_TIMEOUTS (Timeouts) |
|
TMR |
_POSIX_TIMERS (Timers) |
|
TSF |
_POSIX_THREAD_SAFE_FUNCTIONS (Thread-Safe Functions) |
Alignment with the ISO/IEC 9899:1999 standard, including ISO/IEC 9899:1999/Cor.2:2004(E)
A review of the use of fixed path filenames within the standard
For example, the at, batch, and crontab utilities previously had a requirement for use of the directory /usr/lib/cron.
The following were requirements on POSIX.1-2008:
Backward-compatibility
For interfaces carried forward, it was agreed that there should be no breakage of functionality in the existing base documents. All strictly conforming applications will be conforming but not necessarily strictly conforming to the revised standard. The goal is for system implementations to be able to support the existing and revised standards simultaneously.
Architecture and n-bit-neutral
The common standard should not make any implicit assumptions about the system architecture or size of data types; for example, previously some 32-bit implicit assumptions had crept into the standards.
Extensibility
It should be possible to extend the common standard without breaking backwards-compatibility; for example, the name space should be reserved and structured to avoid duplication of names between the standard and extensions to it.
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-2008.
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).
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.
The implementation supports _POSIX_CHOWN_RESTRICTED.
The limit {NGROUPS_MAX} is greater than or equal to 8.
The implementation supports the setting of the group ID of a file (when it is created) to that of the parent directory.
The implementation supports _POSIX_SAVED_IDS.
The implementation supports _POSIX_VDISABLE.
The implementation supports _POSIX_JOB_CONTROL.
The implementation supports _POSIX_NO_TRUNC.
The read() function returns the number of bytes read when interrupted by a signal and does not return -1.
The write() function returns the number of bytes written when interrupted by a signal and does not return -1.
In the environment for the login shell, the environment variables LOGNAME and HOME are defined and have the properties described in POSIX.1-2008.
The value of {CHILD_MAX} is greater than or equal to 25.
The value of {OPEN_MAX} is greater than or equal to 20.
The implementation supports the functionality associated with the symbols CS7, CS8, CSTOPB, PARODD, and PARENB defined in <termios.h>.
See Conformance.
There is no additional rationale provided for this section.
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 www.opengroup.org/austin/defectform.html.
The meanings specified in POSIX.1-2008 for the words shall, should, and may are mandated by ISO/IEC directives.
In the Rationale (Informative) volume of POSIX.1-2008, the words shall, should, and may are sometimes used to illustrate similar usages in POSIX.1-2008. However, the rationale itself does not specify anything regarding implementations or applications.
As a practical matter, the conformance document is effectively part of the system documentation. Conformance documents are distinguished by POSIX.1-2008 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-2008 as if they included the word shall, and facilities thus specified are no less required. For example, the two statements:
The foo() function shall return zero.
The foo() function returns zero.
are meant to be exactly equivalent.
In POSIX.1-2008, 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.
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-2008. 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-2008 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-2008 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".
The term "application" is not defined in POSIX.1-2008; it is assumed to be a part of general computer science terminology.
Three terms used within POSIX.1-2008 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.
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.
This also refers to a C preprocessor symbol, with specific associated requirements. See the definition in Symbolic Constant.
There is no additional rationale provided for this section.
To aid the identification of options within POSIX.1-2008, 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:
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.
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