60
applications follow POSIX rules, it is easier to move
programs from one POSIX-conforming
operating system to another.
Most programmers, and the companies that employ them, understand the benefits of developing
programs that are highly portable across a variety of computer architectures and operating
systems. To write portable programs you want to make use of only those fe
atures on a
particular system that are also found on other systems. Writing POSIX-compliant programs
does, in fact, result in more portable programs. However, writing these programs is not so easy
if you rely solely upon the manufacturer's documentation.
A programming reference manual typically combines POSIX-compliant functions with
non-compliant functions. A function might comply with the POSIX requirements but also add
several new features peculiar to that computer system or operating system variant. A
manufacturer may not always point out what features represent added value and are supported
only on that make or model. Even though the computer system you use might conform to the
POSIX standard, you can still write non-conforming applications by making u
se of the
system-specific features added by the manufacturer.
This book is a guide to the operating system interface as guaranteed by the POSIX standard.
You can write complete, conforming applications by using the information in this book. The
POSIX library of functions is complete enough to write many useful and so
phisticated
applications. However, there are many areas that the POSIX standard does not yet address.
Thus, programmers must implement strategies that isolate nonportable code from
portable-code, such that even hardware-dependent features are easily identi
fied. The object of
this book is to help the programmers resolve portability issues at the design stage of
development, and not after the program has been fully implemented on a particular system.
P
age xxiv
The POSIX Standard Documents
Not many people actually read a standard, nor are they expected to. It is more like reading an
insurance policy. When a standards organization such as ANSI or IEEE publishes a standards
document, they view it as a formal document in which the primary aim i
s to be unambiguous.
The language is very technical and precise. The statements ''Applications should not set
O_XYZ
" and "Applications shall not set
O_XYZ
" mean very different (almost opposite) things.
"Should" means that something is recommended but is not required. "Shall" s
ignifies a
requirement.
The primary aim of this book is to interpret the POSIX standard for the application programmer
and explain it in language that he or she can understand. You can read this book without
remembering the technical meaning of words like
may, should,
or
shall.
The POSIX standard contains a lot of information that was written by and for system
implementers. The standard describes how to write an operating system that conforms to the
POSIX standard. A typical passage is:
All of the described members shall appear in the stat structure. The structure members
st_mode,
st_ino, st_dev, stuid, st_gid, st_atime, st_ctime,
and
st_mtime
shall have meaningful values for all
file types defined in this part of ISO/IEC9945.
*
54
If you are an application programmer, you don't want to know how to construct an operating
system. You need to know how to write programs using the POSIX library to obtain the
services that an operating system provides. What this passage means to an applic
ation
programmer is:
The file size returned by the
stat()
function is only valid for regular files. It may not contain
meaningful information for special files, such as
/dev/tty
.
Finally, the POSIX standard is difficult to use; that is, it is not organized for a programmer who
wants to consult it while writing programs. It follows the conventions of a standards document.
This book is organized for use as a programmer's guide to POS
IX and a reference guide to
POSIX. The organization of this book is described in more detail in the next section.
In the POSIX standard, there are functions that are defined in relation to the ANSI C standard.
Given the additional requirements placed on C standard functions by POSIX, the programmer
has the chore of reading both the C standard and the POSIX standard to
get complete
information. In this book, standard C functions are described in full in one place.
* IEEE Std 1003.1-1990 Section 5.6.1.
P
age xxv
This book is a clearly written, complete guide to writing POSIX-compliant programs. In fact,
you may not need to own a copy of the POSIX standard. Or, if you do have it, we believe that
you will come to rely on the information in this book and find that it
is more accessible.
Guide to POSIX for Programmers
There are two separate guides that make up this book. The first is a programmer's guide to
writing POSIX-compliant programs. It begins with an overview of what the POSIX standard
actually defines. Then it covers the basic ingredients of a POSIX-compliant p
rogram. There are
a set of chapters devoted to explaining the functional areas addressed by the standard. Each
chapter covers a group of related functions. For example, all of the information on terminal I/O
is in Chapter 8. In this part of the book, we di
scuss in more detail the relation between POSIX
and Standard C, a set of issues regarding internationalization and portability, and finally, how
to design programs that isolate system dependencies from POSIX-compliant code.
The second is a reference guide for everyday use. The library functions are listed in alphabetic
order and there are sections covering error message codes, data structures and the standard
header files.
Here is an outline of the book:
Programming Guide
Chapter 1,
Introduction to POSIX and Portability,
answers a number of questions anyone
might have concerning POSIX. It addresses such basic questions as: Why is the POSIX
standard important? What does the POSIX standard cover? What is the relationship betw
een
POSIX and UNIX?
Chapter 2,
Developing POSIX Applications,
covers the basics of writing a POSIX-compliant
71
program. It describes how to make sure your program accesses the POSIX libraries and looks
at the required elements of a conforming program. It also presents a complet
e sample program
that uses many POSIX features. After reading this chapter you can read the following chapters
in any order. If your main interest is POSIX terminal I/O, you can skip right to Chapter 8.
Chapter 3,
Standard File and Terminal I/O,
covers the Input/Output facilities of the Standard
C library. These are highly portable functions that perform general-purpose file operations.
Chapter 4,
Files and Directories,
deals with the file system as defined by POSIX. It covers
directory structures, filenaming conventions and the library functions to manipulate files and
directories.
Chapter 5,
Advanced File Operations,
addresses the basic operations of the POSIX
Input/Output system as well as some advanced concepts like pipes and FIFOs.
P
age xxvi
Chapter 6,
Working with Processes,
covers working with processes. It covers creating and
terminating processes and signals.
Chapter 7,
Obtaining Information at Run-time,
describes how to obtain information about the
environment, such as the user's name or the current time.
Chapter 8,
Terminal I/O,
covers Input/Output to terminals.
Chapter 9,
POSIX and Standard C,
covers POSIX and Standard C. This covers some
portability pitfalls and other features of the Standard C language.
Chapter 10,
Porting to Far-off Lands,
is dedicated to internationalization. That is issues
having to do with porting a program from one culture to another.
Reference Guide and Appendixes
Library Functions
is, by far, is the largest chapter in the book. It is a complete list of library
functions in alphabetic order. Every function is defined in its correct place. For example, the
isspace()
function is not listed under
ctype
as it is in trad
itional UNIX manuals. This
makes this information much easier to find.
Appendix A,
Header Files,
lists the standard headers and the information that they define.
Appendix B,
Data Structures,
is a complete list of data structures and their members.
Appendix C,
Error Codes,
covers all of the error codes.
Appendix D,
Porting from BSD and System V,
provides information on porting applications
from BSD and AT&T System V systems to POSIX.
Appendix E,
Changes and Additions in Standard C,
describes the changes and additions to the
C language made by Standard (ANSI) C.
Appendix F,
Federal Information Processing Standard 151-1,
describes the Federal
Information Processing Standard used by the U.S. Government to purchase systems with
POSIX-like interfaces.
45
Related Publications
lists related publications.
Assumptions
In this book, I assume that you understand the C language and have some experience
programming in C for the UNIX operating system. I also assume knowledge of ANSI C syntax.
By and large, I assume you are an intermediate to expert programmer who is interest
ed in the
substance of POSIX but has little or no interest in reading the standards document to find it out.
P
age xxvii
Conventions
Italic
is used for:
·
New terms where they are defined.
·
Titles of publications.
Typewriter Font
is used for:
·
Anything that would be typed verbatim into code, such as examples of source code and text
on the screen.
·
POSIX functions and headers.
·
UNIX pathnames, filenames, program names, user command names, and options for user
commands.
Sample Programs Available on Internet
The examples in this book are available on
ftp.uu.net
in the directory
/published/oreilly/misc/posix_prguide
P
age 1
Chapter 1
Introduction to POSIX and Portability
This chapter offers a basic introduction to the POSIX standard and the efforts that led to its
development; it also explains the relationship between POSIX and UNIX and the ANSI C
standard.
Early computers each had a unique program architecture and a unique operating system. When
an application needed to be moved from one generation of hardware to the next, it had to be
rewritten. In 1964, IBM introduced the System/360. This was the first fam
ily of compatible
computers. They used one operating system, OS/360, and programs could easily be moved to
more powerful models. A single vendor implementing a single hardware architecture across
56
multiple machines was a first step in achieving portability.
In 1968, AT&T's Bell Labs began work on the UNIX operating system. It allowed a single
operating system to run on multiple hardware platforms from multiple vendors. UNIX,
however, developed along several different lines: AT&T System V, Berkeley Software
Di
stributions, Xenix, and so on. None of the flavors works identically and the precise behavior
of each flavor is not well defined. It can be difficult to move applications from one flavor to
another.
Today there is a major battle of operating systems. Unix Systems Lab's System V, the Open
Software Foundation's OSF/1, Digital Equipment's VAX/VMS, and Microsoft's OS/2 are all
trying to set the standard. Yet, they all agree to support the POSIX standards.
*
POSIX is an international standard with an exact definition and a set of assertions which can be
used to verify compliance. A conforming POSIX application can move from system to system
with a very high confidence of low maintenance and correct operation.
If you want software to
run on the largest possible set of hardware and operating systems, POSIX is the way to go.
POSIX is based on UNIX System V and Berkeley UNIX, but it is not itself an operating system.
POSIX describes the contract between the application and the operating system. POSIX does
not say how to write applications programs or how to write the operating
system. Instead,
POSIX defines the interface between applications and their libraries. POSIX does not talk
about ''system calls" or make any distinction between the kernel and the user.
* AT&T Unix System V release 4.0 and OSF/1 release 1.0 are both POSIX-conforming. Digital
Equipment Corporation and Microsoft have both publicly committed to making their operating
systems POSIX conforming.
P
age 2
POSIX completes the generalization started by IBM with the System/360. POSIX is a standard
independent of vendor, operating system, and architecture.
The formal name for the POSIX standard is
IEEE Standard 1003.1-1988 Portable Operating
System Interface for Computer Environments.
*
We call it POSIX (pronounced
pahz-icks,
similar to
positive).
In fact, IEEE Std 1003.1-1988 is the first of a group of propo
sed standards
collectively known as POSIX.
In 1990 POSIX became International Standard ISO/IEC 9945-1: 1990. The International
Standard is slightly different from IEEE Std 1003.1-1988. The IEEE reaffirmed the standard as
IEEE Std 1003.1-1990. The changes are mainly clarifications with no technical
impact. We
will point out the few significant differences as we go along.
Who is Backing POSIX?
The United States Government has adopted the POSIX standard as a Federal Information
Processing Standard (FIPS 151) for use in computer systems procurement. The European
Community is getting ready to do the same thing. This has inspired the following Syste
m
vendors
**
to announce support for POSIX:
AEG Modcomp
Harris Computer Systems Division
Documents you may be interested
Documents you may be interested
