ISO/IEC 9945-1:1990

I N T E R NAT I O NA L ISO/IEC
STANDARD 9945- 1
IEEE
Std 1003.1
First edition
1990-12-07
Information technology - Portable Operating
System Interface (POSIX) -
Part 1 :
System Application Program Interface (API 1
[C Language]
Technologies de i'information - Interface pour la portabilté des systèmes (POSIXI -
Partie 7 : Interface programme de systèmes d'application (APII [Langage Cl
Reference number
ISO/IEC 9945-1 : 1990 (E)
IEEE Std 1003.1-1990
ISBN 1-55937-061-0
Library of Congress Catalog Number 90-084554
Quote in 8.1.2.3 on Returns is taken from X3.159-1989,
developed under the auspices of the American National Standards
Accredited Committee X3 Technical Committee Wll, Computer and
Business Equipment Manufacturers Association (CBEMA),
311 First St, N.W., Suite 500, Washington, DC 20001.
@Copyright 1990 by
The Institute of Electrical and Electronics Engineers, Inc.
345 East 47th Street, New York, NY 10017, USA
No part of this publication may be reproduced in any form,
in an electronic retried system or oihenuke,
without the prior written permission of the publisher.
Dennater 7.1940
International Standard ISOIIEC 9945-1: 1990
IEEE Std 1003.1-1990
(hvision of IEEE Ski 1003.1-1988)
Information technology-Portable
Operating System Interface (POSIX)
Part 1:
System Application Program Interface
(API) [C Language]
Sponsor
Technical Committee on Operating Systems
and Application Environments
of the
IEEE Computer Society
Approved September 28,1990
lEEE Standards Board
Approved 1990 by the
International Organization for Standardization
and by the
International Electrotechnical Commission
Abstract: ISOAEC 9945-1: 1990 (IEEE Std 1003.1-1990), Information tech-
nology-Portable Operating System Interface (PûSïx)-Part 1: System Applica-
tion Program Interface (MI) [C Language] is part of the POSE series of stan-
for applications and user interfaces to open systems. It denies the appli-
dards
cations interface to basic system services for inputloutput, file system access,
and process management. It also defines a format for data interchange. This
standard is stated in terms of its C binding.
Keywords: MI, application portability, C (programming language), data pro-
cessing, information interchange, open systems, operating system, portable
application, POSIX, programming language, system configuration computer
interface
Adopted 88 an Intemationai Standard by the
International Organization for Standardization
and by the
International Electrotechnical Commission
of Electrical and Electronics Engineers, Inc.

IEEE Standards documents are developed within the Technical Committees of
the IEEE Societies and the Standards Coordinating Committees of the IEEE Stan-
dards Board. Members of the committees serve voluntarily and without compen-
They are not necessarily members of the Institute. The standards
sation.
developed within IEEE represent a consensus of the broad expertise on the subject
wiL>lin the Institute as well as those activities outside of IEEE that have expressed
an interest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard
to produce, test, measure, purchase,
does not imply that there are no other ways
market, or provide other goods and services related to the scope of the IEEE Stan-
dard. 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 fmm users of the standard. Every IEEE Stan-
dard 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 deter-
mine that they have the latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party,
regardless of membership affiliation with IEEE. Suggestions for changes in docu-
ments should be in the form of a proposed change of text, together with appropri-
ate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of por-
tions 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 con-
sensus of all concerned interests, it is important to ensure that any interpretation
has also received the concurrence of a balance of interests. For this reason, the
IEEE and the members of its technical 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 on standards and requests for interpretations should be addressed to:
Secretary, IEEE Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
IEEE Standards documents are adopted by the Institute of Electrical and Elec-
tronics Engineers without regard to whether their adoption may involve
patents on articles, materials, or processes. Such adoption does not assume
any liability to any patent owner, nor does it assume any obligation whatever to
parties adopting the standards documents.

Contents
PAGE
...
Foreword . vlll
...................... ix
Introduction
.................... 1
Section 1: General
1.1 Scope .
1.2 Normative References .
1.3 Conformance .
Section2: TerminologyandGeneralRequirements . . . . 9
................... 9
2.1 Conventions
2.2 Definitions . 10
2.3 General Concepts . 21
2.4 ErrorNumbers . 23
2.5 Primitive System Data Types . 27
2.6 Environment Description . 27
2.7 C Language Definitions . 29
2.8 NumericalLimits . 34
2.9 Symbolic Constants . 37
Section 3: Process Primitives . 41
3.1 Process Creation and Execution . 41
3.1.1 Process Creation . 41
3.1.2 Execute a File . 42
3.2 Process Termination . 46
3.2.1 Wait for Process Termination . 47
3.2.2 Terminate a Process . 49
3.3 Signals . 51
3.3.1 Signal Concepts . 51
3.3.2 Send a Signal to a Process . 56
3.3.3 Manipulate Signal Sets . 57
3.3.4 Examine and Change Signal Action . 58
3.3.5 Examine and Change Blocked Signals . 60
3.3.6 Examine Pending Signals . 62
3.3.7 Wait for a Signal . 62
3.4 Timer Operations . 63
3.4.1 Schedule Alarm . 63
........... 64
3.4.2 Suspend Process Execution
3.4.3 Delay Process Execution . 65
Section 4: Process Environment . 67
4.1 Process Identification . 67
4.1.1 Get Process and Parent Process IDs . 67
..
PAGE
4.2 User Identification . 68
4.2.1 Get Real User. Effective User. Real Group. and Effective
Group IDS . 68
4.2.2 Set User and Group IDS . 68
4.2.3 Get Supplementary Group IDS . 70
4.2.4 Get User Name . 71
4.3 Process Groups . 72
4.3.1 Get Process Group ID . 72
4.3.2 Create Session and Set Process Group ID . 72
4.3.3 Set Process Group ID for Job Control . 73
4.4 System Identification . 74
4.4.1 GetSystemName . 74
4.5 Time . 75
4.5.1 Get System Time . 75
4.5.2 Get Process Times . 76
4.6 Environment Variables . 77
4.6.1 Environment Access . 77
4.7 Terminal Identification . 78
4.7.1 Generate Terminal Pathname . 78
4.7.2 Determine Terminal Device Name . 79
4.8 Configurable System Variables . 80
4.8.1 Get Configurable System Variables . 80
Section 5: Files and Directories 83
...............
5.1 Directories . 83
5.1.1 Format of Directory Entries . 83
5.1.2 Directory Operations . 83
5.2 Working Directory . 86
5.2.1 Change Current Working Directory . 86
5.2.2 Get Working Directory Pathname . 87
5.3 General File Creation .
5.3.1 Open a File . 88
5.3.2 Create a New File or Rewrite an Existing One . 91
5.3.3 Set File Creation Mask .
5.3.4 Link to a File .
5.4 Special File Creation .
5.4.1 Make a Directory . 94
5.4.2 Make a FIFO Special File .
5.5 File Removal .
5.5.1 Remove Directory Entries . 96
5.5.2 Remove a Directory . 98
5.5.3 Rename a File .
5.6 File Characteristics .
5.6.1 File Characteristics: Header and Data
structure .
5.6.2 Get File Status .
5.6.3 Check File Accessibility .
5.6.4 Change File Modes .
5.6.5 Change Owner and Group of a File .
iii
PAGE
5.6.6 Set File Access and Modification Times .
5.7 Configurable Pathname Variables .
5.7.1 Get Confiyrable Pathname Variables .
..... 113
Section6: Input andOutputPrimitives .
..... 113
6.1 Pipes .
6.1.1 Create an Inter-Process Channel . .
.....
6.2 File Descriptor Manipulation .
6.2.1 Duplicate an Open File Descriptor . .
6.3 File Descriptor Deassignment . .
6.3.1 Close a File . .
.....
6.4 Input and Output .
6.4.1 Read from a File . .
.....
6.4.2 Write to a File .
.....
6.5 Control Operations on Files .
.....
6.5.1 Data Definitions for File Control Operations
.....
6.5.2 File Control .
.....
6.5.3 RepositionReadNriteFile Offset .
Section 7: Device- and Class-Specific Functions .
7.1 General Terminal Interface .
7.1.1 Interface Characteristics .
7.1.1.1 Opening a Terminal Device File .
7.1.1.2 Process Groups .
7.1.1.3 The Controlling Terminal .
7.1.1.4 Terminal Access Control .
7.1.1.5 InputProcessingandReadingData .
7.1.1.6 Canonical Mode Input Processing . . . .
7.1.1.7 Noncanonical Mode Input Processing .
7.1.1.8 WritingDataandOutput Processing .
7.1.1.9 Special Characters .
7.1.1.10 Modem Disconnect .
.......
7.1.1.11 Closing a Terminal Device File
7.1.2 ParametersThat CanBeSet .
7.1.2.1 termios Structure .
7.1.2.2 Input Modes .
7.1.2.3 Output Modes .
7.1.2.4 Control Modes .
7.1.2.5 LocalModes .
7.1.2.6 Special Control Characters .
7.1.2.7 BaudRatevalues .
7.1.3 Baud Rate Functions .
7.1.3.1 Synopsis .
7.1.3.2 Description .
7.1.3.3 Returns
7.1.3.4 Errors .
7.1.3.5 Cross-References .
7.2 GeneralTerminal InterfaceControlFunctions .
7.2.1 Get andsetstate .
iv
PAGE
7.2.2 Line Control Functions . 145
7.2.3 Get Foreground Process Group ID . 147
7.2.4 Set Foreground Process Group ID . 148
Section 8: Language-Specific Services for the C Programming
...................... 151
Language
8.1 Referenced C Language Routines . 151
8.1.1 Extensions to Time Functions . 152
8.1.2 Extensions to setlocale( ) Function . 154
8.2 C Language Input/Output Functions . 155
8.2.1 Map a Stream Pointer to a File Descriptor . 156
8.2.2 Open a Stream on a File Descriptor . 157
..... 158
8.2.3 Interactions of Other FILE-Type C Functions
8.2.4 Operations on Files - the remove() Function . 162
8.3 Other C Language Functions . 162
8.3.1 Nonlocal Jumps . 162
8.3.2 SetTimeZone . 162
................ 165
Section9: SystemDatabases
9.1 System Databases . 165
9.2 Database Access . 166
9.2.1 Group Database Access . 166
9.2.2 User Database Access . 167
10: Data Interchange Format . 169
Section
10.1 ArchivelInterchange File Format . 169
10.1.1 Extended tar Format . 169
10.1.2 Extended cpio Format . 173
10.1.3 Multiple Volumes . 177
Annex A (informative) Bibliography . 179
A.l Related Open Systems Standards . 179
A.2 Otherstandards . 181
A.3 HistoricalDocumentation andIntroductory Texts . 182
Annex B (informative) Rationale and Notes . 185
B.l Scope and Normative References .
B.2 Definitions and General Requirements .
B.3 Process Primitives .
B.4 ProcessEnvironment .
B.5 Files and Directories .
B.6 Input and Output Primitives .
B.7 Device- and Class-Specific Functions .
B.8 Language-Specific Services for the C Programming
Language .
B.9 System Databases .
B.10 Data Interchange Format .
Annex C (informative) Headercontents Samples . 301
V
PAGE
Annex D (informative) Profiles . 313
D.l Definitions . 313
D.2 Options in This Part of ISO/IEC 9945 . 314
D.3 Related Standards . 315
D.4 Related Activities . 315
D.5 Relationship to IEEE Draft Project 1003.0 . 315
Annex E (informative) Sample National Profile . 317
E.l (Examp1e)ProfileforDenmark . 318
IdentifierIndex . 321
AlphabeticTopicalIndex . 327
TABLES
Table 2-1 . Primitive System Data Types . 27
Table 2-2 . Reserved Header Symbols . 31
Table2-3 . Minimumvalues . 35
Table 2-4 . Run-Time Increasable Values . . 35
Table 2-5 . Run-Time Invariant Values (Possibly
Indeterminate) . . 36
Table 2-6 . Pathname Variable Values . 36
Table 2-7 . Invariant Value . . 37
Table 2-8 . Symbolic Coiistants for the access() Function . 38
Table 2-9 . Symbolic Constants for the ZseekO Function . . 38
Table 2-10 . Compile-Time Symbolic Constants . . 38
Table 2-11 . Execution-Time Symbolic Constants . . 39
Table 3-1 . Required Signals . . 52
Table 3-2 . Job Control Signals . . 52
Table 4-1 . unum0 Structure Members . . . 75
Table 4-2 . Configurable SystemVariables . . 80
vi
Table 5-1 . stat Structure .
Table 5-2 . Configurable Pathname Variables .
Table 6-1 . cmd Values for fcntZ( ) .
Table 6-2 . File Descriptor Flags Used for fcntZ() .
Table 6-3 . Z-type Values for Record Locking With fcntZ() .
Table 6-4 . oflag Values for open() .
Table 6-5 . File Status Flags Used for open() and fcntZ( ) .
Table 6-6 . File Access Modes Used for open0 and fcntZ() .
Table 6-7 . Mask for Use With File Access Modes .
Table 6-8 . flock Structure .
Table 6-9 . fcntZ( ) Return Values .
Table 7-1 . termios Structure .
Table 7-2 . termios c-iflag Field .
Table 7-3 . termios ccflag Field .
.......
Table 7-4 . termios c-Zflag Field .
.......
Table 7-5 . termios c-cc Special Control Characters
.......
. termiosBaudRateValues .
Table7-6
.......
Tableg-1 . groupStructure . . .
.......
Table 9-2 . passwd Structure . . .
.......
Table 10-1 . tar HeaderBlock . .
.......
Table 10-2 . Byte-Oriented cpio Archive Entry . .
.......
Table 10-3 . Values for cpioc-mode Field .
.......
Table B-1 . Suggested Feature Test Macros .
vii
Foreword
1 IS0 (the International Organization for Standardization) and IEC (the Interna-
I
2 tional Electrotechnical Commission) together form a system for worldwide stan-
3 dardization as a whole. National bodies that are members of IS0 or IEC partici-
I
pate in the development of International Standards through technical committees
I
established by the respective organization to deal with particular fields of techni-
I
cal activity. IS0 and IEC technical committees collaborate in fields of mutual
I
7 interest. Other international organizations, governmental and nongovernmental,
I
8 in liaison with IS0 and IEC, also take part in the work.
I
9 In the field of information technology, IS0 and IEC have established a joint techni-
I
10 cal committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint
I
11 technical committee are circulated to national bodies for approval before their
l
12 acceptance as International Standards. They are approved in accordance with
I
13 procedures requiring at least 75% approval by the national bodies voting.
I
14 International Standard ISO/IEC 9945-1: 1990 was prepared by Joint Technical
I
15 Committee ISO/IEC JTC 1, Information technology.
I
16 ISO/IEC 9945 consists of the following parts, under the general title Information
I
17 technology-Portable operating system interface (POSIXj :
I
- Part 1: System application program interface (MI) CC language]
I
19 - Part 2: Shell and utilities (under development)
I
20 - Part 3: System administration (under development)
I
Annexes A to E of ISOAEC 9945-1 are provided for information only.
I
International Organization for Standardization/International Electrotechnical Commission
Case postale 56 CH-1211 Genève 20 Switzerland
...
Foreword
vlll
Introduction
(This Introduction is not a normative part of ISO/IEC 9945-1 Information technology-Portable
operating system interface (PûsEQ-Part 1: System application programming interface (Mi)
[C Language], but is included for information only.)
1 The purpose of this part of ISO/IEC 9945 is to define a standard operating system
2 interface and environment based on the UNIX~) Operating System documentation
3 to support application portability at the source level. This is intended for systems
implementors and applications software developers.
5 Initially,2) the focus of this part of ISO/IEC 9945 is to provide standardized ser-
I
6 vices via a C language interface. Future revisions are expected to contain bind-
I
7 ings for other programming languages as well as for the C language. This will be
I
8 accomplished by breaking this part of ISO/IEC 9945 into multiple portions-one
I
9 defining core requirements independent of any programming language, and 0th-
I
10 ers composed of programming language bindings.
I
11 will define a set of required services common to
The core requirements portion
I
any programming language that can be reasonably expected to form a language
I
binding to this part of ISOAEC 9945. These services will be described in terms of
I
functional requirements and will not define programming language-dependent
I
15 interfaces. Language bindings will consist of two major parts. One will contain
I
16 the programming language’s standardized interface for accessing the core services
I
defined in the programming language-independent core requirements section of
I
18 this part of ISO/IEC 9945. The other will contain a standardized interface for
I
language-specific services. Any implementation claiming conformance to this part
I
20 of ISOAEC 9945 with any language binding will be required to comply with both
I
21 sections of the language binding.
I
22 Within this document, the term ‘‘POSiX.1,” refers to this part of ISOAEC9945
I
23 itself.
I
24 Organization of This Part of ISOnEC 9945
I
This part of ISO/IEC 9945 is divided into four elements:
(1) Statement of scope and list of normative references (Section 1)
(2) Definitions and global concepts (Section 2)
(3) The various interface facilities (Sections 3 through 9)
(4) Data interchange format (Section 10)
30 1) UNM is a registered trademark of AT&T in the USA and other countries.
2) The vertical rules in the right margin depict technical or significant non-editanal changes from
IEEE Std 1003.1-1988 ta IEEE Std 1003.1-1990. A vertical rule beside an empty line indicates
33 deleted text.
Introduction ix
34 Most of the sections describe a single service interface. The C Language binding
36 for the service interface is given in the subclause labeled Synopsis. The Descrip-
36 tion subclause provides a specification of the operation performed by the service
37 interface. Some examples may be provided to illustrate the interfaces described.
In most cases there are also Returns and Errors subclauses specifying return
values and possible error conditions. References are used to direct the reader to
other related sections. Additional material to complement sections in this part of
41 ISO/IEC 9945 may be found in the Rationale and Notes, Annex B. This annex pro-
vides historical perspectives into the technical choices made by the developers of
this part of ISO/IEC 9945. It also provides information to emphasize consequences
of the interfaces described in the corresponding section of this part of
ISOIIEC 9945.
46 Informative annexes are not part of the standard and are provided for information
only. (There is a type of annex called "normative" that is part of a standard and
48 imposes requirements, but there are currently no such normative annexes in this
part of ISOIIEC 9945.) They are provided for guidance and to help understanding.
50 In publishing this part of ISO/IEC 9945, its developers simply intend to provide a
51 yardstick against which various operating system implementations can be meas-
52 ured for conformance. It is not the intent of the developers to measure or rate any
53 products, to reward or sanction any vendors of products for conformance or lack of
conformance to this part of ISOIIEC 9945, or to attempt to enforce this part of
55 ISO/IEC 9945 by these or any other means. The responsibility for determining the
56 degree of conformance or lack thereof with this part of ISO/IEC 9945 rests solely
with the individual who is evaluating the product claiming to be in conformance
with this part of ISO/IEC 9945.
59 Base Documents
60 The various interface facilities described herein are based on the 1984 lusrlgroup
Standard derived and published by the UniForum (formerly /usr/group) Stan-
I
dards Committee. The 1984 lusrlgroup Standard and this part of ISO/IEC 9945
are largely based on UNIX Seventh Edition, UNIX System III, UNIX System V,
64 4.2BSD, and 4.3BSD d~umentation,~) but wherever possible, compatibility with
other systems derived from the UNIX operating system, or systems compatible
with that system, has been maintained.
Background
The developers of POSIX.l represent a cross-section of hardware manufacturers,
vendors of operating systems and other software development tools, software
designers, consultants, academics, authors, applications programmers, and oth-
71 ers. In the course of their deliberations, the developers reviewed related Ameri-
can and international standards, both published and in progress.
Conceptually, YOSIX.1 describes a set of fundamental services needed for the
efficient construction of application programs. Access to these services has been
75 3) The IEEE is grateful to both AT&T and UniForum for permission to use their materials.
Introduction
X
76 provided by defining an interface, using the C programming language, that estab-
77 lishes standard semantics and syntax. Since this interface enables application
writers to write portable applications-it was developed with that goal in mind-
79 it has been designated POSIX,4) an acronym for Portable Operating System
80 Interface.
Although originated to refer to IEEE Std 1003.1-1988, the name POSIX more
82 correctly refers to a family of related standards: IEEE 1003.12 and the parts of
83 ISOhEC 9945. In earlier editions of the IEEE standard,
International Standard
a4
the term POSM was used as a synonym for IEEE Std 1003.1-1988. A preferred
term, POSXX.1, emerged. This maintained the advantages of readability of the
symbol "POSIX" without being ambiguous with the POSIX family of standards.
B?
88 The intended audience for ISOAEC 9945 is all persons concerned with an
89 industry-wide standard operating system based on the UNE system. This
90 includes at least four groups of people:
(1) Persons buying hardware and software systems;
(2) Persons managing companies that are deciding on future corporate com-
93 puting directions;
(3) Persons implementing operating systems, and especially
(4) Persons developing applications where portability is an objective.
puFpo=
97 Several principles guided the development of this part of ISO/IEC 9945:
I
98 Application Oriented
The basic goal was to promote portability of application programs across
I
UNM system environments by developing a clear, consistent, and unam-
10 1
biguous standard for the interface specification of a portable operating
102 system based on the UNIX system documentation. This part of
103 ISOAEC 9945 codifies the common, existing definition of the UNIX sys-
104 tem. There was no attempt to define a new system interface.
105 Interface, Not Implementation
106 This part of ISO/IEC 9945 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
109 function are given (although historical practice is sometimes indicated
in AnnexB). Symbolic names are given for constants (such as signals
and error numbers) rather than numbers.
4) The name PûSM was suggested by Richard Stallman. It is expected to be pronounced phz-icks,
as in positive, not poh-six, or other variations. The pronunciation has been published in an
114 attempt to promulgate a standardized way of referring to a standard operating system interface.
xi
Introduction
115 Source, Not Object, Portability
116 This part of ISO/IEC 9945 has been written so that a program written
117 and translated for execution on one conforming implementation may
118 also be translated for execution on another conforming implementation.
119 This part of ISO/IEC 9945 does not guarantee that executable (object or
120 binary) code will execute under a different conforming implementation
12 1 than that for which it was translated, even if the underlying hardware
122 is identical. However, few impediments were placed in the way of
123 binary compatibility, and some remarks on this are found in Annex B.
124 See B.1.3.1.1 and B.4.8.
125 The C Language
126 This part of ISO/IEC 9945 is written in terms of the standard C language
127 as specified in the C Standard (21.') See B.1.3 and B.l.l.l.
128 No Super-User, No System Administration
129 There was no intention to specify all aspects of an operating system.
130 System administration facilities and functions are excluded from
13 1 POSIX.1, and functions usable only by the super-user have not been
132 included. Annex B notes several such instances. Still, an implementa-
133 tion of the standard interface may also implement features not in this
134 part of ISO/IEC 9945; see 1.3.1.1. This part of ISO/IEC 9945 is also not
concerned with hardware constraints or system maintenance.
Minimal Interface, Minimally Defined
137 In keeping with the historical design principles of the UNE system,
138 POSIXl is as minimal as possible. For example, it usually specifies only
139 of functions to implement a capability. Exceptions were made in
one set
some cases where long tradition and many existing applications
14 1 included certain functions, such as weat(). In such cases, as throughout
142 POSIX.1, redundant definitions were avoided: weat( ) is defined as a spe-
cial case of openo. Redundant functions or implementations with less
tradition were excluded. I
145 Broadly Implementable
The developers of POSIX.l endeavored to make all specified functions
I
implementable across a wide range of existing and potential systems,
including:
(1)
All of the current major systems that are ultimately derived from I
the original mix system code (Version 7 or later)
I
(2) Compatible systems that are not derived from the original UNE I
system code I
153 5) The number in braces corresponds to those of the references in 1.2 (or the bibliographic entry in
154 Annex A if the number is preceded by the letter B).
xii
Introduction
155 (3) Emulations hos rent operating systems
156 (4) Networked systems
157 (5) Distributed systems
158 (6) Systems running on a broad range of hardware
159 No direct references to this goal appear in this part of TSO/IEC 9945, but
160 some results of it are mentioned in Annex B.
16 1 Minimal Changes to Historical Implementations
162 There are no known historical implementations that will not have to
163 change in some area to conform to this part of ISOhEC 9945, and in a
164 few areas POSIX.l does not exactly match any existing system interface
165 (for example, see the discussion of O-NONBLOCK in B.6). Nonetheless,
166 there is a set of functions, types, definitions, and concepts that form an
167 interface that is common to most historical implementations. POSIX.l
168 specifies that common interface and extends it in areas where there has
169 historically been no consensus, preferably
(1) By standardizing an interface like one in an historical implemen-
171 tation; e.g., directories, or;
172 (2) By specifying an interface that is readily implementable in terms
173 of, and backwards compatible with, historical implementations,
174 such as the extended tar format in 10.1.1, or;
175 (3) By specifying an interface that, when added to an historical imple-
176 mentation, will not conflict with it, like B.6.
177 Required changes to historical implementations have been kept to a
178 minimum, but they do exist, and Annex B points out some of them.
179 PoSIXl is specifically not a codification of a particular vendor‘s product.
180 It is similar to the UNE system, but it is not identical to it.
181 It should be noted that implementations will have different kinds of
182 extensions. Some will reflect “historical usage” and will be preserved for
183 execution of pre-existing applications. These functions should be con-
184 sidered “obsolescent” and the standard functions used for new applica-
185 tions. Some extensions will represent functions beyond the scope of
186 PoSIX1. These need to be used. with careful management to be able to
187 adapt to future POSMLl extensions and/or port to implementations that
provide these services in a dif’ferent manner,
189 Minimal Changes to Existing Application Code
190 A goal of POSIX.1 was to minimize additional work for the developers of
I
19 1 applications. However, because every known historical implementation
I
192 will have to change at least slightly to conform, some applications will
193 have to change. AnnexB points out the major places where POSIXl
194 implies such changes.
Introduction xiii
195 Related Standards Activities
196 Activities to extend this part of ISO/IEC 9945 to address additional requirements
197 are in progress, and similar efforts can be anticipated in the future.
The following areas are under active consideration at this time, or are expected to I
become active in the near future?
I
Language-independent service descriptions of this part of ISOAEC 9945
I
C, Ada, and FORTRAN Language bindings to (1)
I
Shell and Utility facilities I
Verification testing methods I
Realtime facilities I
Secure/Trusted System considerations I
Network interface facilities I
System Administration I
Graphical User Interfaces I
209 Profiles describing application- or user-specific combinations of Open Sys-
210 tems standards for: supercomputing, multiprocessor, and batch exten-
sions; transaction processing; realtime systems; and multiuser systems
212 based on historical models
213 An overall guide to POSIX-based or related Open Systems standards and
profiles
Extensions are approved as “amendments” or “revisions” to this document, follow-
216 ing the IEEE and ISO/IEC Procedures.
Approved amendments are published separately until the full document is
reprinted and such amendments are incorporated in their proper positions.
219 If you have interest in participating in the TCOS working groups addressing these
220 issues, please send your name, address, and phone number to the Secretary, IEEE
221 Standards Board, Institute of Electrical and Electronics Engineers, Inc., P.O. Box
222 1331,445 Hoes Lane, Piscataway, NJ 08855-1331, and ask to have this forwarded
223 TCOS working group. If you have interest in
to the chairperson of the appropriate
224 participating in this work at the international level, contact your ISO/IEC national
225 body.
6) A Standards Status Report that lists all current ïEEE Computer Society fitandards projects is
available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC
20036-1903; Telephone: +1202 371-0101; FAX: +1202 728-9614. Working drafts of POSIX
standards under development are also available from this office.
Introduction
xiv
.1 Working Group, sponsored by
IEEE Std 1003.1-1990 was pr
the Technical Committee on Operating Systems and Application Environments of
the IEEE Computer Society. At the time this standard was approved, the
membership of the 1003.1 Working Group was as follows:
Technical Committee on Operating Systems
and Application Environments (WOS)
Chair: Luis-Felipe Cabrera
Standards Subcommittee for TCOS
Chair: Jim Isaak
Treasurer: Quin Hahn
Secretary: Shane McCanon
1003.1 Working Group Officials
Chair: Donn Terry
Vice Chair: Keith Stuck
Editor: Hal Jespersen
Secretary: Keith Stuck
Working Group
Neguine Navab
Greg Goddard
Steve Bartels
Paul Rabin
Andrew Griffith
Robert Bismuth
Seth Rosenthal
Rand Hoven
James Bohem
Lorne Schachter
Randall Howard
Kathy Bohrer
Steve Schwann
Mike Karels
Keith Bostic
Paul Shaughnessy
Jeff Kimmel
Jonathan Brown
Steve Sommars
David Korn
Tim Carter
Ravi Tavakley
Bob Lenk
Myles Connors
Jeff Tofano
Shane McCarron
Landon Curt Nol1
David Willcox
John Meyer
Dave Decot
John Wu
Martha Nalebuff
Mark Doran
Glenn Fowler
xv
Introduction
The following persons were members of the 1003.1 Balloting Group that approved
the standard for submission to the IEEE Standards Board
David Chinn Open Software Foundation Znstitutional Representative
Michael Lambert Xf Open Institutional Representative
UniForum Znstitutional Representative
Heinz Lycklama
WzX International Institutional Representative
Shane McCarron
Martha Nalebuff
William Henderson
Helene Armitage
Barry Needham
Lee A. Hollaar
David Athersych
Alan F. Nugent
Terrence Holm
Timothy Baker
Jim Oldroyd
Randall Howard
Geoff Baldwin
Craig Partridge
Irene Hu
Steven E. Barber
John Peace
Andrew Huber
Robert Barned
John C. Penney
Richard Hughes-Rowlands
John Barr
P. Plauger
Judith Hurwitz
James Bohem
Gerald Powell
Jim Isaak
Kathryn Bohrer
Scott E. Preece
Dan Iuster
Robert Borochoff
Joseph Ramus
Richard James
Keith Bostic
Wendy Rauch
Hal Jespersen
James P. Bound
Carol Raye
Michael J. Karels
Joseph Boykin
Wayne B. Reed
sol Kavy
Kevin Brady
Christopher J. Riddick
Lorraine C. Kevra
Phyllis Eve Bregman
Andrew K. Roach
JeBey S. Kimmel
F’red Lee Brown, Jr.
Robert Sarr
M. J. Kirk
A. Winsor Brown
Lorne H. Schachter
Dale Kirkland
Luis-Felipe Cabrera
Norman Schneidewind
John T. Kline
Nicholas A. Camillone
Stephen Schwann
Kenneth Klingman
Clyde Camp
Richard Scott
Joshua Knight
John Carson
Leonard Seagren
Andrew R. Knipp
Steven Carter
Glen Seeds
David Kom
Jerry Cashin
Karen Sheaffer
Don Kretsch
Kilnam Chon
Charles Smith
Takahiko Kuki
Anthony Cincotta
Steven Sommars
Thomas Kwan
Mark Colburn
Douglas H. Steves
Robin B. Lake
Donald W. Cragun
James Tanner
Mark Lamonds
Ana Maria DeAlvare
Ravi Tavakley
Doris Lebovits
Dave Decot
Marc Teitelbaum
Maggie Lee
Steven Deller
Donn S. Terry
Greger Leijonhufvud
Terence Dowling
Gary F. Tom
Robert Lenk
Stephen A. Dum
Andrew Twigger
David Lennert
John D. Earls
Mark-Rene Uchida
Donald Lewine
Ron Elliott
L. David Umbaugh
Kevin Lewis
David Emery
Michael W. Vannier
F. C. Lim
Philip H. Enslow
David John Wallace
James Lonjers
Ken Faubel
Stephen Walli
Warren E. Loper
Kester Fong
Larry Wehr
Roger Martin
Kenneth R. Gibb
Bruce Weiner
Martin J. McGowan
Michel Gien
Robert Weissensee
Marshall McKusick
Gregory W. Goddard
P. J. Weyman
Robert McWhirter
Dave Grindeland
Andrew Wheeler, Jr.
Paul Merry
Judy Guist
David Willcox
Doug Michels
James Hall
F. Wright
Randall
Gary W. Miller
Charles Hammons
ûren Yuen
James Moe
Allen Hankinson
Jason Zions
James W. Moore
Steve Head
Barry Hedquist
Introduction
XVi
When the IEEE Standards Board approved this standard on September 28, 1990,
it had the following membership:
James M. Daly, Vice Chairman
Marco W. Migliaro, Chairman
Andrew G. Salem, Secretary
Kenneth D. Hendrix Lawrence V. McCall
Dennis Bodson
John W. Horch L. Bruce McClung
Paul L. Borrill
Joseph L. Koepfinger* Donald T. Michael*
Fietcher J. Buckley
Irving Kolodny Stig Nilsson
Allen L. Clapp
Michael A. Lawler Roy T. Oishi
Stephen R. Dillon
Donald J. Loughry Gary S. Robinson
Donald C. Fleckenstein
Terrance R. Whittemore
John E. May, Jr.
Jay Forster*
Donald W. Zip-
Thomas L. Hannan
*Member Emeritus
xvii
Introduction
INTERNATIONAL STANDARD ISO/IEC 9945-1: 1990
Information technology-Portable operating
system interface (PO$IX)-Part 1: System
application programming interface (NI)
[C Language]
Section 1: General
1 1.1 scope
2 This part of ISO/IEC 9945 defines a standard operating system interface and
environment to support application portability at the source-code level. It is
4 intended to be used by both application developers and system implementors.
I
5 This part of ISO/IEC 9945 comprises four major components:
(1) Terminology, concepts, and definitions and specifications that govern
structures, headers, environment variables, and related requirements
8 (2) Definitions for system service interfaces and subroutines
(3) Language-specific system services for the C programming language
10 (4) Interface issues, including portability, error handling, and error recovery
11 ISO/IEC 9945:
The following areas are outside of the scope of this part of
12 (1) User interface (shell) and associated commands
13 (2) Networking protocols and system call interfaces to those protocols
14 (3) Graphics interfaces
15 (4) Database management system interfaces
16 (5) Record U0 considerations
1.1 Scope
ISO/IEC 9945-1: 1990
INFORMATION TECHNOLOGY-POSIX
IEEE Std 1003.1-1990
17 (6) Object or binary code portability
18 (7) System configuration and resource availability
(8) The behavior of system services on systems supporting concurrency
20 within a single process
21 This part of ISO/IEC 9945 describes the external characteristics and facilities that
22 are of importance to applications developers, rather than the internal construc-
23 tion techniques employed to achieve these capabilities. Special emphasis is
24 placed on those functions and facilities that are needed in a wide variety of com-
25 mercial applications.
This part of ISü/IEC 9945 has been defined exclusively at the source-code level.
The objective is that a Strictly Conforming POSIX.l Application source program
28 can be translated to execuk sn a cmhrming iïaplementation.
1.2 Normative References I
30 The following standards contain provisions which, through references in this text,
I
31 constitute provisions of this part of ISO/IEC 9945. At the time of publication, the
I
32 editions indicated were valid. All standards are subject to revision, and parties to
I
agreements based on this part of this International Standard are encouraged to
I
34 investigate the possibility of applying the most recent editions of the standards
I
35 listed below. Members of IEC and IS0 maintain registers of currently valid Inter-
I
36 national Standards.
I
37 (11 ISO/IEC 646: 1983, ') Information processing-IS0 7-bit coded character set
I
for information interchange.
I
39 (2) ISO/IEC 9899: . . . ,2) Information technology-Programming languages-C.
I
40 1.3 Conformance
41 1.3.1 Implementation Conformance
42 1.3.1.1 Requirements
43 A conforming implementation shall meet all of the following criteria:
44 1) Under revision. (This notation is meant to explicitly reference the 1990 Draft International
45 Standard version of ISO/sEC 646.)
46 ISO/IEC documents can be obtained from the IS0 office, 1, rue de Varembé, Case Postale 56, CH-
47 1211, Genève 20, SwitzerlandSuisse.
2) To be approved and published.
1 General
ISOAEC 9946-1: 1990
Part 1: SYSTEM API [C LANGUAGE] IEEE Std 1003.1-1990
(1) The system shall support all required interfaces defined within this part
50 of ISOAEC 9945.
These interfaces shall support the functional behavior
51 described herein.
(2) The system may provide additional functions or facilities not required by
this part of ISO/IEC 9945. Nonstandard extensions should be identified
54 as such in the system documentation. Nonstandard extensions, when
55 used, may change the behavior of functions or facilities defined by this
56 part of ISO/IEC9945. The conformance document shall define an
environment in which an application can be run with the behavior
specified by the standard. In no case shall such an environment require
modification of a Strictly Conforming POSIx.1 Application.
60 1.3.1.2 Documentation
61 A conformance document with the following information shall be available for an
62 ISOAEC 9945. The confor-
implementation claiming conformance to this part of
mance document shall have the same structure as this part of ISO/IEC 9945, with
the information presented in the appropriately numbered sections, clauses, and
65 subclauses. The conformance document shall not contain information about
66 extended facilit
...