IEEE Std 1003.1-2001 is one of a family of standards known as POSIX. The family of standards extends to many topics; IEEE Std 1003.1-2001 is known as POSIX.1 and consists of both operating system interfaces and shell and utilities. IEEE Std 1003.1-2001 is technically identical to The Open Group Base Specifications, Issue 6, which comprise the core volumes of the Single UNIX Specification, Version 3.
The (paraphrased) goals of this development were to produce a single common revision to the overlapping POSIX.1 and POSIX.2 standards, and the Single UNIX Specification, Version 2. As such, the scope of the revision includes the scopes of the original documents merged.
Since the revision includes merging the Base volumes of the Single UNIX Specification, many features that were previously not "adopted" into earlier revisions of POSIX.1 and POSIX.2 are now included in IEEE Std 1003.1-2001. In most cases, these additions are part of the XSI extension; in other cases the standard developers decided that now was the time to migrate these to the base standard.
The Single UNIX Specification programming environment provides a broad-based functional set of interfaces to support the porting of existing UNIX applications and the development of new applications. The environment also supports a rich set of tools for application development.
The majority of the obsolescent material from the existing POSIX.1 and POSIX.2 standards, and material marked LEGACY from The Open Group's Base specifications, has been removed in this revision. New members of the Legacy Option Group have been added, reflecting the advance in understanding of what is required.
The following IEEE standards have been added to the base documents in this revision:
IEEE Std 1003.1d-1999
IEEE Std 1003.1j-2000
IEEE Std 1003.1q-2000
IEEE P1003.1a draft standard
IEEE Std 1003.2d-1994
IEEE P1003.2b draft standard
Selected parts of IEEE Std 1003.1g-2000
Only selected parts of IEEE Std 1003.1g-2000 were included. This was because there is much duplication between the XNS, Issue 5.2 specification (another base document) and the material from IEEE Std 1003.1g-2000, the former document being aligned with the latest networking specifications for IPv6. Only the following sections of IEEE Std 1003.1g-2000 were considered for inclusion:
General terms related to sockets (Section 2.2.2)
Socket concepts (Sections 5.1 through 5.3 inclusive)
The pselect() function (Sections 6.2.2.1 and 6.2.3)
The <sys/select.h> header (Section 6.2)
The following were requirements on IEEE Std 1003.1-2001:
Backward-compatibility
It was agreed that there should be no breakage of functionality in the existing base documents. This requirement was tempered by changes introduced due to interpretations and corrigenda on the base documents, and any changes introduced in the ISO/IEC 9899:1999 standard (C Language).
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.
Previous revisions of POSIX.1 built upon the ISO C standard by reference only. This revision takes a different approach.
The standard developers believed it essential for a programmer to have a single complete reference place, but recognized that deference to the formal standard had to be addressed for the duplicate interface definitions between the ISO C standard and the Single UNIX Specification.
It was agreed that where an interface has a version in the ISO C standard, the DESCRIPTION section should describe the relationship to the ISO C standard and markings should be added as appropriate to show where the ISO C standard has been extended in the text.
A block of text was added to the start of each affected reference page stating whether the page is aligned with the ISO C standard or extended. Each page was 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 U.S. government procurement standards managed and maintained on behalf of the U.S. Department of Commerce by the National Institute of Standards and Technology (NIST).
The following restrictions have been made in this version of IEEE Std 1003.1 in order to align with FIPS 151-2 requirements:
The implementation supports _POSIX_CHOWN_RESTRICTED.
The limit {NGROUPS_MAX} is now 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 IEEE Std 1003.1-2001.
The value of {CHILD_MAX} is now greater than or equal to 25.
The value of {OPEN_MAX} is now 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.
The meanings specified in IEEE Std 1003.1-2001 for the words shall, should, and may are mandated by ISO/IEC directives.
In the Rationale (Informative) volume of IEEE Std 1003.1-2001, the words shall, should, and may are sometimes used to illustrate similar usages in IEEE Std 1003.1-2001. 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 IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001, 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". 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 withdrawn without the grace period obsolescence implies. The phrase "may be considered for withdrawal in future revisions" 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 added for compatibility with the Single UNIX Specification. It means "this feature is historic and optional; do not use this feature in new applications. There are alternative interfaces that are more suitable.". It is used exclusively for XSI extensions, and includes facilities that were mandatory in previous versions of the base document but are optional in this revision. This is a way to "sunset" the usage of certain functions. Application writers should not rely on the existence of these facilities in new applications, but should follow the migration path detailed in the APPLICATION USAGE sections of the relevant pages.
The terms "legacy" and "obsolescent" are different: a feature marked LEGACY is not recommended for new work and need not be present on an implementation (if the XSI Legacy Option Group is not supported). A feature noted as obsolescent is supported by all implementations, but may be removed in a future revision; new applications should not use these features.
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 IEEE Std 1003.1-2001. 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 IEEE Std 1003.1-2001 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 many places IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001; it is assumed to be a part of general computer science terminology.
Three terms used within IEEE Std 1003.1-2001 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.
This can also refer to a C preprocessor symbol (without arguments), but is also used to refer to the names for characters in character sets. In addition, it is sometimes used to refer to host names and even filenames.
This also refers to a C preprocessor symbol (also without arguments).
In most cases, the difference in semantic content is negligible to nonexistent. Readers should not attempt to read any meaning into the various usages of these terms.
To aid the identification of options within IEEE Std 1003.1-2001, a notation consisting of margin codes and shading is used. This is based on the notation used in previous revisions of The Open Group's 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 THR in the margin, it will be available on all systems supporting the Threads option, but may not be available on some others.
This section includes codes for options defined in the Base Definitions volume of IEEE Std 1003.1-2001, Section 2.1.6, 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.