ISO/IEC 9945-2:2002

INTERNATIONAL ISO/IEC
STANDARD 9945-2
System Interfaces,
IEEE Std 1003.1
Second edition
2002-12-15
Information technology — Portable ®
Operating System Interface (POSIX )—
Part 2:
System Interfaces
Technologies de l'information — Interface pour la portabilité des systèmes ®
(POSIX )—
Partie 2: Interfaces systèmes
Reference number
System Interfaces, IEEE Std 1003.1-2001

System Interfaces, IEEE Std 1003.1-2001
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
ISO
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
™
IEEE Std 1003.1 -2001
(Revision of IEEE Std 1003.1-1996
and IEEE Std 1003.2-1992)
The Open Group Technical Standard
Base Specifications, Issue 6
Information technology—Portable ®
Operating System Interface (POSIX )
Part 2: System Interfaces
Sponsor
Portable Applications Standards Committee
of the
IEEE Computer Society
and
The Open Group
Abstract
This standard defines a standard operating system interface and environment, including a command interpreter (or ‘‘shell’’), and
common utility programs to support applications portability at the source code level. It is the single common revision to IEEE Std

1003.1-1996, IEEE Std 1003.2-1992, and the Base Specifications of The Open Group Single UNIX † Specification, Version 2. This
standard is intended to be used by both applications developers and system implementors and comprises four major components
(each in an associated volume):
• General terms, concepts, and interfaces common to all volumes of this standard, including utility conventions and C-language
header definitions, are included in the Base Definitions volume.
• Definitions for system service functions and subroutines, language-specific system services for the C programming language,
function issues, including portability, error handling, and error recovery, are included in the System Interfaces volume.
• Definitions for a standard source code-level interface to command interpretation services (a ‘‘shell’’) and common utility
programs for application programs are included in the Shell and Utilities volume.
• Extended rationale that did not fit well into the rest of the document structure, containing historical information concerning the
contents of this standard and why features were included or discarded by the standard developers, is included in the Rationale
(Informative) volume.
The following areas are outside the scope of this standard:
• Graphics interfaces
• Database management system interfaces
• Record I/O considerations
• Object or binary code portability
• System configuration and resource availability
This standard describes the external characteristics and facilities that are of importance to applications developers, rather than the
internal construction techniques employed to achieve these capabilities. Special emphasis is placed on those functions and facilities
that are needed in a wide variety of commercial applications.
Keywords
application program interface (API), argument, asynchronous, basic regular expression (BRE), batch job, batch system, built-in
utility, byte, child, command language interpreter, CPU, extended regular expression (ERE), FIFO, file access control mechanism,

input/output (I/O), job control, network, portable operating system interface (POSIX †), parent, shell, stream, string, synchronous,
system, thread, X/Open System Interface (XSI)
________________________
† See Trademarks (on page xxii).

System Interfaces, IEEE Std 1003.1-2001
International Standard ISO/IEC 9945-2:2002(E)
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of the joint technical Committee is to prepare International Standards. Draft International Standards
adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 9945 may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 9945-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 22, Programming languages, their environments and system software interfaces.
This second edition of ISO/IEC 9945-2, together with ISO/IEC 9945-1, ISO/IEC 9945-3 and ISO/IEC 9945-4,
cancels and replaces ISO/IEC 9945-1:1996 and ISO/IEC 9945-2:1993, which have been technically revised.
ISO/IEC 9945 consists of the following parts, under the general title Information technology — Portable Operating ®
System Interface (POSIX ):
 Part 1: Base Definitions
 Part 2: System Interfaces
 Part 3: Shell and Utilities
 Part 4: Rationale
International Organization for Standardization / International Electrotechnical Commission
Case postale 56 • CH-1211 Genève 20 • Switzerland

reserved. This printing is by the International Organization for Standardization with special permission of the Institute of
Electrical and Electronics Engineers, Inc. and The Open Group. Published in Switzerland.
System Interfaces, Issue 6.
Published 6 December 2001 by the Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, U.S.A.
ISBN: 0-7381-3436-8 PDF 0-7381-3431-7/SS95047 CD-ROM 0-7381-3426-0/SE95047
Printed in the United States of America by the IEEE.
Published 6 December 2001 by The Open Group
Apex Plaza, Forbury Road, Reading, Berkshire RG1 1AX, U.K.
Document Number: C951
ISBN: U.K. 1-85912-252-3 U.S. 1-931624-08-9
Printed in the U.K. by The Open Group.
All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise,
without prior written permission from both the IEEE and The Open Group.
Portions of this standard are derived with permission from copyrighted material owned by Hewlett-Packard Company,
International Business Machines Corporation, Novell Inc., The Open Software Foundation, and Sun Microsystems, Inc.
Permissions
Authorization to photocopy portions of this standard for internal or personal use is granted provided that the appropriate fee is
paid to the Copyright Clearance Center or the equivalent body outside of the U.S. Permission to make multiple copies for edu-
cational purposes in the U.S. requires agreement and a license fee to be paid to the Copyright Clearance Center.
Beyond these provisions, permission to reproduce all or any part of this standard must be with the consent of both copyright
holders and may be subject to a license fee. Both copyright holders will need to be satisfied that the other has granted permis-
sion. Requests to the copyright holders should be sent by email to austin-group-permissions@opengroup.org.
Feedback
This standard has been prepared by the Austin Group. Feedback relating to the material contained in this standard may be
submitted using the Austin Group web site at http://www.opengroup.org/austin/defectform.html.

IEEE
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE
Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process,
approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and
interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE
does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property, or other damage, of any
nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication,
use of, or reliance upon this, or any other IEEE Standard document.
The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any
express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use
of the material contained herein is free from patent infringement. IEEE Standards documents are supplied ‘‘AS IS’’.
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or
provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a
standard is approved and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or
reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its
contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine
that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on
behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any
person utilizing this, and any other IEEE Standards document, should rely upon the advice of a competent professional in
determining the exercise of reasonable care in any given circumstances.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific
applications. When the need for interpretations is brought to the attention of the IEEE, the Institute will initiate action to prepare
appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any
interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases
where the matter has previously received formal consideration.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with the
IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate
supporting comments. Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, U.S.A.
__________________________________________________________________________________________________________________
LLAttention is called to the possibility that implementation of this standard may require use of subject matter covered by patent
LL
rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in
LL
connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEELL
LStandard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.L
LL
A patent holder has filed a statement of assurance that it will grant licenses under these rights without compensation or underLL
Lreasonable rates and non-discriminatory, reasonable terms and conditions to all applicants desiring to obtain such licenses. TheL
LLIEEE makes no representation as to the reasonableness of rates and/or terms and conditions of the license agreements offered by
LL
patent holders. Further information may be obtained from the IEEE Standards Department.
_LL_________________________________________________________________________________________________________________LL
The IEEE and its designees are the sole entities that may authorize the use of IEEE-owned certification marks and/or trademarks to
indicate compliance with the materials set forth herein. Authorization to photocopy portions of any individual standard for internal
or personal use is granted in the U.S. by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is
paid to the Copyright Clearance Center. Permission to photocopy portions of any individual standard for educational classroom
use can also be obtained through the Copyright Clearance Center. To arrange for payment of the licensing fee, please contact:
Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923, U.S.A., Tel.: +1 978 750 8400
Amendments, corrigenda, and interpretations for this standard, or information about the IEEE standards development process, may
be found at http://standards.ieee.org.
Full catalog and ordering information on all IEEE publications is available from the IEEE Online Catalog & Store at
http://shop.ieee.org/store.
________________________
1. For this standard, please send comments via the Austin Group as requested on page iii.
2. Please refer to the special provisions for this standard on page iii concerning permissions from both copyright holders and arrangements to cover photocopying and
reproduction across the world, as well as by commercial organizations wishing to license the material for use in product documentation.

The Open Group
The Open Group, a vendor and technology-neutral consortium, is committed to delivering greater business efficiency by bringing
together buyers and suppliers of information technology to lower the time, cost, and risks associated with integrating new
technology across the enterprise.
The Open Group’s mission is to offer all organizations concerned with open information infrastructures a forum to share knowledge,
integrate open initiatives, and certify approved products and processes in a manner in which they continue to trust our impartiality.
In the global eCommerce world of today, no single economic entity can achieve independence while still ensuring interoperability.
The assurance that products will interoperate with each other across differing systems and platforms is essential to the success of
eCommerce and business workflow. The Open Group, with its proven testing and certification program, is the international
guarantor of interoperability in the new century.
The Open Group provides opportunities to exchange information and shape the future of IT. The Open Group’s members include
some of the largest and most influential organizations in the world. The flexible structure of The Open Groups membership allows
for almost any organization, no matter what their size, to join and have a voice in shaping the future of the IT world.
More information is available on The Open Group web site at http://www.opengroup.org.
The Open Group has over 15 years’ experience in developing and operating certification programs and has extensive experience
developing and facilitating industry adoption of test suites used to validate conformance to an open standard or specification. The
Open Group portfolio of test suites includes the Westwood family of tests for this standard and the associated certification program
for Version 3 of the Single UNIX Specification, as well tests for CDE, CORBA, Motif, Linux, LDAP, POSIX.1, POSIX.2, POSIX
Realtime, Sockets, UNIX, XPG4, XNFS, XTI, and X11. The Open Group test tools are essential for proper development and
maintenance of standards-based products, ensuring conformance of products to industry-standard APIs, applications portability,
and interoperability. In-depth testing identifies defects at the earliest possible point in the development cycle, saving costs in
development and quality assurance.
More information is available at http://www.opengroup.org/testing.
The Open Group publishes a wide range of technical documentation, the main part of which is focused on development of Technical
and Product Standards and Guides, but which also includes white papers, technical studies, branding and testing documentation,
and business titles. Full details and a catalog are available at http://www.opengroup.org/pubs.
As with all live documents, Technical Standards and Specifications require revision to align with new developments and associated
international standards. To distinguish between revised specifications which are fully backwards compatible and those which are
not:
• A new Version indicates there is no change to the definitive information contained in the previous publication of that title, but
additions/extensions are included. As such, it replaces the previous publication.
•
A new Issue indicates there is substantive change to the definitive information contained in the previous publication of that title,
and there may also be additions/extensions. As such, both previous and new documents are maintained as current publications.
Readers should note that Corrigenda may apply to any publication. Corrigenda information is published at
http://www.opengroup.org/corrigenda.
Full catalog and ordering information on all Open Group publications is available at http://www.opengroup.org/pubs.

Contents
Chapter 1 Introduction. 1
1.1  Scope. 1
1.2  Conformance . 1
1.3  Normative References . 1
1.4  Change History . 1
1.5  Terminology. 1
1.6  Definitions . 3
1.7  Relationship to Other Formal Standards . 3
1.8  Portability . 3
1.8.1   Codes. 3
1.9  Format of Entries. 11
Chapter 2 General Information . 13
2.1  Use and Implementation of Functions . 13
2.2  The Compilation Environment. 13
2.2.1   POSIX.1 Symbols . 13
2.2.1.1     The _POSIX_C_SOURCE Feature Test Macro. 14
2.2.1.2     The _XOPEN_SOURCE Feature Test Macro. 14
2.2.2   The Name Space. 14
2.3  Error Numbers. 21
2.3.1   Additional Error Numbers. 28
2.4  Signal Concepts. 28
2.4.1   Signal Generation and Delivery. 28
2.4.2   Realtime Signal Generation and Delivery . 29
2.4.3   Signal Actions. 31
2.4.4   Signal Effects on Other Functions . 34
2.5  Standard I/O Streams. 34
2.5.1   Interaction of File Descriptors and Standard I/O Streams. 35
2.5.2   Stream Orientation and Encoding Rules . 37
2.6  STREAMS . 38
2.6.1   Accessing STREAMS. 39
2.7  XSI Interprocess Communication . 39
2.7.1   IPC General Description. 40
2.8  Realtime . 41
2.8.1   Realtime Signals. 41
2.8.2   Asynchronous I/O . 41
2.8.3   Memory Management . 43
2.8.3.1     Memory Locking. 43
2.8.3.2     Memory Mapped Files. 43
2.8.3.3     Memory Protection. 44
2.8.3.4     Typed Memory Objects . 44
2.8.4   Process Scheduling . 44
System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved. vii

Contents
2.8.5   Clocks and Timers . 48
2.9  Threads. 50
2.9.1   Thread-Safety. 50
2.9.2   Thread IDs. 51
2.9.3   Thread Mutexes. 51
2.9.4   Thread Scheduling. 52
2.9.5   Thread Cancelation . 54
2.9.5.1     Cancelability States . 54
2.9.5.2     Cancelation Points . 55
2.9.5.3     Thread Cancelation Cleanup Handlers. 57
2.9.5.4     Async-Cancel Safety. 57
2.9.6   Thread Read-Write Locks. 58
2.9.7   Thread Interactions with Regular File Operations . 58
2.10  Sockets. 58
2.10.1   Address Families. 58
2.10.2   Addressing . 59
2.10.3   Protocols . 59
2.10.4   Routing. 59
2.10.5   Interfaces. 59
2.10.6   Socket Types. 59
2.10.7   Socket I/O Mode. 60
2.10.8   Socket Owner. 60
2.10.9   Socket Queue Limits . 60
2.10.10   Pending Error. 60
2.10.11   Socket Receive Queue. 61
2.10.12   Socket Out-of-Band Data State . 61
2.10.13   Connection Indication Queue . 62
2.10.14   Signals . 62
2.10.15   Asynchronous Errors . 62
2.10.16   Use of Options. 63
2.10.17   Use of Sockets for Local UNIX Connections. 66
2.10.17.1     Headers . 66
2.10.18   Use of Sockets over Internet Protocols. 66
2.10.19   Use of Sockets over Internet Protocols Based on IPv4. 67
2.10.19.1     Headers . 67
2.10.20   Use of Sockets over Internet Protocols Based on IPv6. 67
2.10.20.1     Addressing . 67
2.10.20.2     Compatibility with IPv4. 68
2.10.20.3     Interface Identification. 68
2.10.20.4     Options. 69
2.10.20.5     Headers . 70
2.11  Tracing. 70
2.11.1   Tracing Data Definitions. 71
2.11.1.1     Structures. 71
2.11.1.2     Trace Stream Attributes. 75
2.11.2   Trace Event Type Definitions . 76
2.11.2.1     System Trace Event Type Definitions . 76
2.11.2.2     User Trace Event Type Definitions. 79
viii System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved.

Contents
2.11.3   Trace Functions. 79
2.12  Data Types. 80
Chapter 3 System Interfaces . 83
Index. 1663
List of Tables
2-1 Value of Level for Socket Options. 63
2-2 Socket-Level Options. 64
2-3 Trace Option: System Trace Events. 77
2-4 Trace and Trace Event Filter Options: System Trace Events. 78
2-5 Trace and Trace Log Options: System Trace Events. 78
2-6 Trace, Trace Log, and Trace Event Filter Options: System Trace Events.79
2-7 Trace Option: User Trace Event . 79
System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved. ix

Foreword
Structure of the Standard
This document was originally developed by the Austin Group, a joint working group of
members of the IEEE, members of The Open Group, and members of ISO/IEC Joint Technical
Committee 1, as one of the four volumes of IEEE Std 1003.1-2001. The standard was approved by
ISO and IEC and published in four parts, correlating to the original volumes.
A mapping of the parts to the volumes is shown below:
______________________________________________________________________________________
LLLLISO/IEC 9945 IEEE Std 1003.1 Description
LLLL
Part Volume
______________________________________________________________________________________
______________________________________________________________________________________
LLLL
9945-1 Base Definitions General terms, concepts, and interfaces common to all
LLLL
parts of ISO/IEC 9945, including utility conventions andLLLL
LLLLC-language header definitions, are included.
______________________________________________________________________________________
LLLL
9945-2 System Interfaces Definitions for system service functions and subroutines,LLLL
LLLlanguage-specific system services for the CL
LLLLprogramming language, function issues, including
LLLL
portability, error handling, and error recovery, are
LLLL
included.
L______________________________________________________________________________________LLL
LLLL9945-3 Shell and Utilities Definitions for a standard source code-level interface to
LLLL
command interpretation services (a ‘‘shell’’) and
LLLL
common utility programs for application programs are
LLLL
included.
L_L_____________________________________________________________________________________LL
LLLL
9945-4 Rationale Extended rationale that did not fit well into the rest of
LLLL
the document structure, containing historical
LLLL
information concerning the contents of ISO/IEC 9945
LLLL
and why features were included or discarded by theLLLL
LLLLstandard developers, is included.
_L_____________________________________________________________________________________LLL
All four parts comprise the entire standard, and are intended to be used together to accomodate
significant internal referencing among them. POSIX conforming systems are required to support
all four parts.
x System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved.

Introduction
Note: This introduction is not part of IEEE Std 1003.1-2001, Standard for Information Technology —
Portable Operating System Interface (POSIX).
This standard has been jointly developed by the IEEE and The Open Group. It is both an IEEE
Standard and an Open Group Technical Standard.
The Austin Group
This standard was developed, and is maintained, by a joint working group of members of the
IEEE Portable Applications Standards Committee, members of The Open Group, and members
of ISO/IEC Joint Technical Committee 1. This joint working group is known as the Austin
Group. The Austin Group arose out of discussions amongst the parties which started in early
1998, leading to an initial meeting and formation of the group in September 1998. The purpose of
the Austin Group has been to revise, combine, and update the following standards: ISO/IEC
9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the Base Specifications of The
Open Group Single UNIX Specification.
After two initial meetings, an agreement was signed in July 1999 between The Open Group and
the Institute of Electrical and Electronics Engineers (IEEE), Inc., to formalize the project with the
first draft of the revised specifications being made available at the same time. Under this
agreement, The Open Group and IEEE agreed to share joint copyright of the resulting work. The
Open Group has provided the chair and secretariat for the Austin Group.
The base document for the revision was The Open Group’s Base volumes of its Single UNIX
Specification, Version 2. These were selected since they were a superset of the existing POSIX.1
and POSIX.2 specifications and had some organizational aspects that would benefit the audience
for the new revision.
The approach to specification development has been one of ‘‘write once, adopt everywhere’’,
with the deliverables being a set of specifications that carry the IEEE POSIX designation and The
Open Group’s Technical Standard designation, and, if approved, an ISO/IEC designation. This
set of specifications forms the core of the Single UNIX Specification, Version 3.
This unique development has combined both the industry-led efforts and the formal
standardization activities into a single initiative, and included a wide spectrum of participants.
The Austin Group continues as the maintenance body for this document.
Anyone wishing to participate in the Austin Group should contact the chair with their request.
There are no fees for participation or membership. You may participate as an observer or as a
contributor. You do not have to attend face-to-face meetings to participate; electronic
participation is most welcome. For more information on the Austin Group and how to
participate, see http://www.opengroup.org/austin.
__________________
3. The Austin Group is named after the location of the inaugural meeting held at the IBM facility in Austin, Texas in September
1998.
System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved. xi

Introduction
Background
The developers of this standard represent a cross section of hardware manufacturers, vendors of
operating systems and other software development tools, software designers, consultants,
academics, authors, applications programmers, and others.
Conceptually, this standard describes a set of fundamental services needed for the efficient
construction of application programs. Access to these services has been provided by defining an
interface, using the C programming language, a command interpreter, and common utility
programs that establish standard semantics and syntax. Since this interface enables application
writers to write portable applications—it was developed with that goal in mind—it has been
designated POSIX, an acronym for Portable Operating System Interface.
Although originated to refer to the original IEEE Std 1003.1-1988, the name POSIX more correctly
refers to a family of related standards: IEEE Std 1003.n and the parts of ISO/IEC 9945. In earlier
editions of the IEEE standard, the term POSIX was used as a synonym for IEEE Std 1003.1-1988.
A preferred term, POSIX.1, emerged. This maintained the advantages of readability of the
symbol ‘‘POSIX’’ without being ambiguous with the POSIX family of standards.
Audience
The intended audience for this standard is all persons concerned with an industry-wide standard
operating system based on the UNIX system. This includes at least four groups of people:
1. Persons buying hardware and software systems
2. Persons managing companies that are deciding on future corporate computing directions
3. Persons implementing operating systems, and especially
4. Persons developing applications where portability is an objective
Purpose
Several principles guided the development of this standard:
• Application-Oriented
The basic goal was to promote portability of application programs across UNIX system
environments by developing a clear, consistent, and unambiguous standard for the interface
specification of a portable operating system based on the UNIX system documentation. This
standard codifies the common, existing definition of the UNIX system.
• Interface, Not Implementation
This standard defines an interface, not an implementation. No distinction is made between
library functions and system calls; both are referred to as functions. No details of the
implementation of any function are given (although historical practice is sometimes
indicated in the RATIONALE section). Symbolic names are given for constants (such as
signals and error numbers) rather than numbers.
__________________
4. The name POSIX was suggested by Richard Stallman. It is expected to be pronounced pahz-icks,as in positive , not poh-six,or
other variations. The pronunciation has been published in an attempt to promulgate a standardized way of referring to a
standard operating system interface.
xii System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved.

Introduction
• Source, Not Object, Portability
This standard has been written so that a program written and translated for execution on one
conforming implementation may also be translated for execution on another conforming
implementation. This standard does not guarantee that executable (object or binary) code
will execute under a different conforming implementation than that for which it was
translated, even if the underlying hardware is identical.
• The C Language
The system interfaces and header definitions are written in terms of the standard C language
as specified in the ISO C standard.
• No Superuser, No System Administration
There was no intention to specify all aspects of an operating system. System administration
facilities and functions are excluded from this standard, and functions usable only by the
superuser have not been included. Still, an implementation of the standard interface may also
implement features not in this standard. This standard is also not concerned with hardware
constraints or system maintenance.
• Minimal Interface, Minimally Defined
In keeping with the historical design principles of the UNIX system, the mandatory core
facilities of this standard have been kept as minimal as possible. Additional capabilities have
been added as optional extensions.
• Broadly Implementable
The developers of this standard endeavored to make all specified functions implementable
across a wide range of existing and potential systems, including:
1. All of the current major systems that are ultimately derived from the original UNIX
system code (Version 7 or later)
2. Compatible systems that are not derived from the original UNIX system code
3. Emulations hosted on entirely different operating systems
4. Networked systems
5. Distributed systems
6. Systems running on a broad range of hardware
No direct references to this goal appear in this standard, but some results of it are mentioned
in the Rationale (Informative) volume.
• Minimal Changes to Historical Implementations
When the original version of IEEE Std 1003.1 was published, there were no known historical
implementations that did not have to change. However, there was a broad consensus on a set
of functions, types, definitions, and concepts that formed an interface that was common to
most historical implementations.
The adoption of the 1988 and 1990 IEEE system interface standards, the 1992 IEEE shell and
utilities standard, the various Open Group (formerly X/Open) specifications, and the
subsequent revisions and addenda to all of them have consolidated this consensus, and this
revision reflects the significantly increased level of consensus arrived at since the original
versions. The earlier standards and their modifications specified a number of areas where
consensus had not been reached before, and these are now reflected in this revision. The
authors of the original versions tried, as much as possible, to follow the principles below
System Interfaces, Issue 6 — Copyright  2001, IEEE and The Open Group. All rights reserved. xiii

Introduction
when creating new specifications:
1. By standardizing an interface like one in an historical implementation; for example,
directories
2. By specifying an interface that is readily implementable in terms of, and backwards-
compatible with, historical implementations, such as the extended tar format defined in
the pax utility
3. By specifying an interface that, when added to an historical implementation, will not
conflict with it; for example, the sigaction() function
This revision tries to minimize the number of changes required to implementations which
conform to the earlier versions of the approved standards to bring them into conformance
with the current standard. Specifically, the scope of this work excluded doing any ‘‘new’’
work, but rather collecting into a single document what had been spread across a number of
documents, and presenting it in what had been proven in practice to be a more effective way.
Some changes to prior conforming implementations were unavoidable, primarily as a
consequence of resolving conflicts found in prior revisions, or which became apparent when
bringing the various pieces together.
However, since it references the 1999 version of the ISO C standard, and no longer supports
‘‘Common Usage C’’, there are a number of unavoidable changes. Applications portability is
similarly affected.
This standard is specifically not a codification of a particular vendor’s product.
It should be noted that implementations will have different kinds of extensions. Some will
reflect ‘‘historical usage’’ and will be preserved for execution of pre-existing applications.
These functions should be considered ‘‘obsolescent’’ and the standard functions used for
...