Operating SystemsPOSIX Interface

POSIX Interface: The Portable Operating System Standard

LevelIntermediate

Duration90 mins

TopicPOSIX Interface

1 / 5

The POSIX Standard

The Portability Crisis That Shaped Modern Computing

Imagine writing a complex application that works perfectly on your development system—only to discover it completely fails on your client's machines. Not because of bugs in your code, but because every Unix variant behaves differently. This was the reality of software development in the 1980s, and it threatened to fragment the computing industry into incompatible islands.

POSIX (Portable Operating System Interface) emerged as the solution to this crisis. Today, POSIX is so foundational that most developers interact with POSIX-compliant interfaces daily without realizing it—from shell scripting to system programming, from Docker containers to cloud infrastructure.

What You Will Learn

By the end of this page, you will understand the historical context that made POSIX necessary, the standardization process that created it, the complete structure of the POSIX specification, and why POSIX remains critically important for modern operating system development.

The Unix Fragmentation Problem

To understand POSIX, we must first understand the chaos it was designed to resolve. The story begins with Unix itself—a revolutionary operating system that became too successful for its own good.

The Birth and Spread of Unix (1969-1980s)

Unix was developed at AT&T Bell Labs beginning in 1969 by Ken Thompson, Dennis Ritchie, and others. When it was rewritten in C in 1973, Unix became remarkably portable—a departure from the assembly-language systems of the era. AT&T distributed Unix to universities and research institutions, leading to widespread adoption and innovation.

But AT&T's licensing terms prohibited them from supporting Unix commercially. This created a critical vacuum: everyone wanted Unix, but no one had official responsibility for its evolution.

The AT&T Consent Decree

A 1956 antitrust consent decree prohibited AT&T from entering the computer business, which meant they could license Unix to universities at nominal cost but couldn't sell it commercially or provide support. This seemingly minor regulatory footnote shaped the entire trajectory of operating system history.

The Great Divergence

Without centralized control, Unix evolved in multiple directions simultaneously:

BSD Unix developed at the University of California, Berkeley, added virtual memory, TCP/IP networking, and the famous Berkeley sockets API
AT&T System V became the 'official' commercial Unix after AT&T was broken up in 1984
Xenix (Microsoft's Unix variant) targeted microcomputers
SunOS/Solaris, HP-UX, AIX, and IRIX each added proprietary extensions

Each variant maintained the Unix philosophy, but diverged in critical implementation details. A program written for BSD might not compile on System V. System calls had different names, different arguments, different semantics.

The Unix Wars: Incompatibilities Between Major Variants
Feature	BSD Unix	AT&T System V	Impact on Portability
Terminal I/O	`ioctl()` with `sgttyb`	`ioctl()` with `termio`	Programs had to implement both interfaces
String Operations	`index()`, `rindex()`	`strchr()`, `strrchr()`	Different function names for identical operations
Networking	Berkeley sockets	STREAMS/TLI	Completely different network programming models
Job Control	Native support	Added later, differently	Shell scripts behaved unpredictably
Signal Handling	Reliable signals	Unreliable signals	Critical race conditions in portable code
Directory Reading	`readdir()` returns `direct`	`readdir()` returns `dirent`	Structure layout differences caused crashes

The Business Impact

This fragmentation created severe business problems:

Vendor Lock-in: Once you chose an HP system, your software was effectively tied to HP. Migration required major rewrites.
Duplicated Development Effort: Software vendors maintained separate codebases for each Unix variant, multiplying costs.
Stunted Market Growth: Potential customers hesitated to adopt Unix precisely because they feared choosing the 'wrong' variant.
Training Fragmentation: System administrators needed expertise in specific variants, reducing labor mobility.

The industry needed standardization—but who would create it, and how could competing vendors agree?

The Birth of POSIX

The Portable Operating System Interface emerged from a confluence of industry pressure, government requirements, and technical vision. Understanding this history illuminates why POSIX takes its particular form.

The /usr/group Initiative (1984)

The standardization effort began with /usr/group (later UniForum), an industry Unix user organization. In 1984, they formed a working group to develop a standard Unix interface specification. This grassroots effort, driven by users rather than vendors, set the tone for POSIX development.

IEEE Takes the Lead (1985)

The Institute of Electrical and Electronics Engineers (IEEE) formalized the effort as Project 1003. The designation 'POSIX' was suggested by Richard Stallman—the 'X' emphasizing the Unix heritage while the name conveyed 'Portable Operating System Interface.'

Why 'POSIX' and Not 'Unix'?

The name 'Unix' is a trademark (now held by The Open Group). POSIX carefully defines a standard interface that any operating system can implement, not a specific implementation. This distinction allowed non-Unix systems like Windows NT to become partially POSIX-compliant.

The Federal Government Mandate (1988)

A pivotal moment came when the U.S. federal government mandated POSIX compliance for computer system procurement. The Federal Information Processing Standard (FIPS) 151 required that systems purchased by federal agencies support POSIX.1. This single requirement transformed POSIX from an aspirational standard into a business necessity.

Vendors who wanted government contracts—a massive market—had to implement POSIX. Even Microsoft added a POSIX subsystem to Windows NT.

IEEE Std 1003.1-1988: The First POSIX Standard

The original POSIX.1 standard, officially IEEE Std 1003.1-1988, focused on the core operating system interface:

Process management (fork(), exec(), wait())
File and directory operations (open(), read(), write(), close())
User and group identity
Signals
Terminal interfaces
Basic I/O operations

This first standard was deliberately minimal—it specified what was common and stable across Unix implementations, deferring contentious areas for future work.

POSIX Design Principles

•Codify Existing Practice — POSIX standardized what already worked, rather than inventing new interfaces. If multiple implementations existed, the standard chose the most common approach or allowed both.
•Minimal Mandatory Requirements — The core standard was kept small to maximize implementability. Optional features were clearly marked as extensions.
•Source-Level Portability — POSIX targets source code compatibility, not binary compatibility. Programs should compile unchanged on different systems.
•C Language Binding — POSIX defines its interface in terms of C function calls and headers, establishing C as the systems programming language.
•Backward Compatibility — Each revision maintains compatibility with previous versions where possible, protecting existing software investments.

Evolution of the POSIX Family

POSIX never stood still. The initial 1988 standard spawned a family of related standards, each addressing additional functionality. Understanding this evolution reveals how operating systems gained standardized interfaces for increasingly complex capabilities.

The POSIX Family Tree

The IEEE 1003 family grew rapidly through the 1990s:

Major POSIX Standards and Their Scope
Standard	Name	Scope	Year
1003.1	System Interface	Core OS API, file I/O, process control	1988, 1990, 1996, 2001, 2008, 2017
1003.2	Shell and Utilities	Shell syntax, standard utilities (ls, grep, awk)	1992
1003.1b	Real-Time Extensions	Real-time signals, semaphores, shared memory, async I/O	1993
1003.1c	Threads	POSIX threads (pthreads) API	1995
1003.1d	Additional Real-Time	Sporadic server, typed memory	1999
1003.1g	Networking	Protocol-independent interfaces	2000
1003.1j	Advanced Real-Time	Barriers, spinlocks, reader-writer locks	2000

The Single UNIX Specification Merger

In 2001, a landmark merger consolidated multiple Unix standardization efforts:

POSIX (IEEE 1003.x)
The Single UNIX Specification (SUS) from The Open Group
ISO/IEC 9945 (the international version of POSIX)

The result was a unified specification: IEEE Std 1003.1-2001, also known as the Single UNIX Specification Version 3 (SUSv3). This consolidation eliminated the confusion of tracking multiple overlapping standards.

The Modern Standard: POSIX.1-2017

The current version, IEEE Std 1003.1-2017 (also SUSv4 2018 edition), represents decades of refinement. It includes:

The base definitions (concepts, headers, and terminology)
System interfaces (the C language API)
Shell and utilities (command interpreter and tools)
Rationale (explanatory material, non-normative)

This specification runs to over 4,000 pages and defines more than 1,000 functions, 80+ utilities, and the complete shell command language.

Accessing the POSIX Standard

The complete POSIX specification is freely available online at pubs.opengroup.org. While reading the full standard isn't necessary for everyday programming, consulting it resolves ambiguities and reveals the precise semantics of system calls.

Key Additions Over Time

Each major revision added capabilities reflecting contemporary computing needs:

POSIX.1-1990: Formalized job control, symbolic links, and terminal handling
POSIX.1b-1993: Real-time extensions for deterministic scheduling and timing
POSIX.1c-1995: Thread support, enabling portable multi-threaded programming
POSIX.1-2001: Large file support, timestamping, additional security functions
POSIX.1-2008: Added openat() family, improved signal safety specifications
POSIX.1-2017: Refined specifications, deprecated obsolete functions, Unicode clarifications

Structure of the POSIX Specification

Understanding how POSIX is organized helps you navigate the specification and understand which guarantees apply to your code. The modern POSIX standard consists of four major volumes:

Volume 1: Base Definitions (XBD)

This volume establishes the foundation for everything else. It defines:

Terminology: Precise meanings for terms like 'process,' 'thread,' 'file descriptor,' and 'signal.'
Conformance Requirements: What an implementation must do to claim POSIX compliance.
Header Specifications: The contents of each standard header file (<unistd.h>, <fcntl.h>, <pthread.h>, etc.).
Locale Definitions: How internationalization works.
Environment Variables: Standard variables like PATH, HOME, LANG.
Regular Expressions: Two syntaxes—Basic Regular Expressions (BRE) and Extended Regular Expressions (ERE).
Directory Structure: Where standard files are located (/bin, /etc, /tmp, etc.).

Volume 2: System Interfaces (XSH)

This is the heart of POSIX for systems programmers. For each function, the specification provides:

Function Specification Components

•NAME — The function name and one-line description
•SYNOPSIS — Required headers and function prototype
•DESCRIPTION — Complete behavioral specification, including edge cases
•RETURN VALUE — What the function returns on success and failure
•ERRORS — All possible error conditions and corresponding errno values
•EXAMPLES — (Sometimes) Code demonstrating correct usage
•APPLICATION USAGE — Guidance for programmers using the function
•RATIONALE — Historical context and design decisions
•FUTURE DIRECTIONS — Planned changes or deprecations
•SEE ALSO — Related functions and concepts

POSIX open() Specification Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/* NAME */
open - open file relative to directory file descriptor
 
/* SYNOPSIS */
#include <fcntl.h>
 
int open(const char *path, int oflag, ...);
int openat(int fd, const char *path, int oflag, ...);
 
/* DESCRIPTION (abbreviated) */
The open() function shall establish the connection between a file
and a file descriptor. It shall create an open file description
that refers to a file and a file descriptor that refers to that
open file description.
 
/* RETURN VALUE */
Upon successful completion, these functions shall return a 
non-negative integer representing the file descriptor. Otherwise, 
-1 shall be returned and errno set to indicate the error.
 
/* ERRORS */
EACCES - Permission denied
EEXIST - O_CREAT and O_EXCL set, file exists
EINTR  - Signal received during open()
ENOENT - File does not exist and O_CREAT not set
ENOSPC - No space left on device (when creating)
... (over 20 possible error conditions)

Volume 3: Shell and Utilities (XCU)

This volume specifies the command-line environment:

Shell Command Language: Complete grammar and semantics for sh
Standard Utilities: Specifications for 160+ commands (ls, grep, awk, sed, make, etc.)
Utility Conventions: Standard option formats, exit codes, and behaviors

The shell specification is particularly detailed because portable shell scripts must behave identically across systems.

Volume 4: Rationale (XRAT)

This non-normative volume explains why decisions were made. It includes:

Historical context for interfaces
Discussions of alternatives considered
Guidance on implementation
Clarifications of ambiguous points

While not binding, the rationale is invaluable for understanding design intent.

Option Groups and Feature Test Macros

POSIX recognizes that not all systems can implement all features. The standard handles this through option groups—collections of related functionality that implementations may or may not provide.

Understanding Option Groups

Each option group has a symbolic constant indicating its support status. The value of this constant tells you how the feature is implemented:

POSIX Option Group Values
Value	Meaning	Implication
`-1`	Feature not supported	Related functions may not exist or will fail with `ENOSYS`
`0`	Compile-time check unavailable	Must use `sysconf()` or `pathconf()` at runtime
`> 0`	Feature supported	All related functions are available

Major Option Groups

Some significantly impact portable programming:

_POSIX_THREADS: Thread support (pthreads)
_POSIX_REALTIME_SIGNALS: Real-time signal extensions
_POSIX_SEMAPHORES: POSIX semaphores
_POSIX_SHARED_MEMORY_OBJECTS: shm_open() and related functions
_POSIX_MEMORY_PROTECTION: Memory protection via mprotect()
_POSIX_ASYNCHRONOUS_IO: Asynchronous I/O operations
_POSIX_FSYNC: File synchronization guarantees

Feature Test Macros

POSIX uses feature test macros to control which declarations are visible. These prevent namespace pollution and enable strict conformance testing:

feature_test_macros.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/* Must be defined BEFORE any header includes */
 
/* Request POSIX.1-2008 features */
#define _POSIX_C_SOURCE 200809L
 
/* Or request full Single UNIX Specification */
#define _XOPEN_SOURCE 700
 
/* For GNU-specific extensions */
#define _GNU_SOURCE
 
/* For BSD-specific extensions */
#define _BSD_SOURCE
 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
 
int main(void) {
    /* Check if threads are supported */
    #if _POSIX_THREADS > 0
        printf("POSIX threads supported
");
    #elif _POSIX_THREADS == 0
        /* Runtime check needed */
        long threads = sysconf(_SC_THREADS);
        if (threads > 0) {
            printf("POSIX threads supported (runtime check)
");
        }
    #else
        printf("POSIX threads not supported
");
    #endif
    
    return 0;
}

Define Feature Test Macros First

Feature test macros MUST be defined before any system header includes. Many programmers place them as the first lines in their source file, or use compiler flags like -D_POSIX_C_SOURCE=200809L. Defining them after headers are included has no effect.

Runtime Capability Checking

Because compile-time checks aren't always sufficient, POSIX provides runtime query functions:

sysconf(): Query system-wide configuration values
pathconf() / fpathconf(): Query path-specific limits
confstr(): Query configuration strings

These functions let your program adapt to the actual capabilities of the system it's running on:

runtime_checking.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <unistd.h>
#include <limits.h>
#include <errno.h>
 
void check_system_capabilities(void) {
    /* Query the maximum length of arguments to exec functions */
    long arg_max = sysconf(_SC_ARG_MAX);
    if (arg_max == -1) {
        perror("sysconf _SC_ARG_MAX");
    } else {
        printf("Maximum argument length: %ld bytes
", arg_max);
    }
    
    /* Query the number of processors */
    long nprocs = sysconf(_SC_NPROCESSORS_ONLN);
    if (nprocs > 0) {
        printf("Online processors: %ld
", nprocs);
    }
    
    /* Query path-specific limits */
    long name_max = pathconf("/", _PC_NAME_MAX);
    if (name_max == -1) {
        if (errno == 0) {
            printf("No limit on filename length
");
        } else {
            perror("pathconf _PC_NAME_MAX");
        }
    } else {
        printf("Maximum filename length: %ld
", name_max);
    }
    
    /* Query the POSIX version supported */
    long posix_version = sysconf(_SC_VERSION);
    printf("POSIX version: %ld
", posix_version);
    /* 200809L means POSIX.1-2008 */
}

Conformance and Compliance Levels

POSIX defines precise language for discussing standards compliance. Understanding these terms helps you evaluate system capabilities and write truly portable code.

Normative Language

The POSIX standard uses specific words with precise meanings:

POSIX Normative Terminology
Term	Meaning	Example
shall	Absolute requirement	`open()` shall return a file descriptor
shall not	Absolute prohibition	A process shall not access freed memory
should	Recommended but not required	Implementations should minimize latency
may	Optional feature	The system may support asynchronous I/O
undefined	No requirements, behavior unpredictable	Reading uninitialized memory is undefined
unspecified	Implementation must document behavior	Scheduling order among equal-priority processes
implementation-defined	Implementation chooses, must document	Maximum number of open file descriptors

Conformance Levels

Implementations can claim different levels of POSIX conformance:

POSIX Conformant: Implements the mandatory portions of POSIX.1
POSIX Compliant: Implements mandatory portions plus one or more option groups
XSI Conformant: Implements the full X/Open System Interfaces extension (includes internationalization, additional utilities, and features from traditional Unix)
UNIX Certified: Has passed The Open Group's official certification test suite

The UNIX® Trademark

Only systems that pass The Open Group's certification can use the UNIX® trademark. This involves:

Running a comprehensive test suite (over 5,000 tests)
Documenting all implementation-defined behavior
Paying certification fees
Regular recertification

Certified systems include macOS, Solaris, HP-UX, and AIX. Linux, despite being highly POSIX-compatible, is not certified as UNIX (primarily due to cost and the philosophical stance of the community).

Linux and POSIX Compliance

Linux aims for practical POSIX compatibility rather than formal certification. Most POSIX-conforming programs run without modification on Linux. Where Linux deviates, it typically offers the POSIX behavior as an option (e.g., through specific mount options or sysctl settings).

The POSIX Namespace

POSIX carefully manages the namespace—the names available for use by implementations, applications, and the standard itself. This prevents collisions between your code and system libraries.

Reserved Namespaces

POSIX reserves certain naming patterns for its own use:

Names Reserved by POSIX

•Names starting with underscore + uppercase — _Uppercase, __anything: Reserved for the implementation (compiler, library)
•Names starting with double underscore — __name: Reserved regardless of following character
•Names ending with _t — Reserved for type definitions (e.g., size_t, pid_t)
•Names starting with E + digit or uppercase — Reserved for additional error numbers (e.g., EAGAIN)
•Names starting with SIG + uppercase — Reserved for signal names (e.g., SIGKILL)
•Names starting with is or to + lowercase — Reserved for character testing/conversion (e.g., isdigit, toupper)
•Names starting with str, mem, or wcs — Reserved for string/memory/wide-string functions

Why This Matters

Respecting reserved namespaces prevents subtle, hard-to-debug errors:

namespace_violations.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/* DON'T DO THIS - These names are reserved */
 
typedef int size_t;          /* WRONG: _t suffix reserved */
#define EINVALID 500         /* WRONG: E + uppercase reserved */
void strappend(char *s);     /* WRONG: str + lowercase reserved */
int _Private_function(void); /* WRONG: _ + uppercase reserved */
 
/* DO THIS INSTEAD */
 
typedef int my_size;          /* OK: no reserved suffix */
#define MY_ERR_INVALID 500    /* OK: different prefix */
void my_strappend(char *s);   /* OK: unique prefix */
int private_function(void);   /* OK: no leading underscore */
 
/* Project-specific prefixes prevent ALL conflicts */
typedef int proj_size;
#define PROJ_ERR_INVALID 500
void proj_strappend(char *s);

Practical Advice

Professional codebases use project-specific prefixes for all exported symbols (functions, types, macros). This eliminates any risk of namespace collision with current or future POSIX additions. Examples: glib_, apr_, ev_.

Summary: The POSIX Standard

We have covered the complete foundation of POSIX—from its historical origins through its current structure. Let's consolidate the essential knowledge:

Key Takeaways

•POSIX Solved Fragmentation — Without POSIX, the Unix ecosystem would have fractured into incompatible islands. The standard enabled a portable software industry.
•POSIX Defines Interfaces, Not Implementations — Any operating system can implement POSIX interfaces. This separates the API contract from specific implementations.
•The Standard Has Four Volumes — Base Definitions (XBD), System Interfaces (XSH), Shell and Utilities (XCU), and Rationale (XRAT) together form the complete specification.
•Option Groups Handle Variability — Not all features are mandatory. Feature test macros and runtime queries let code adapt to available capabilities.
•Normative Language Is Precise — Words like 'shall,' 'should,' and 'may' have specific meanings that affect how implementations and applications must behave.
•Namespace Management Prevents Conflicts — Reserved naming patterns ensure that applications don't collide with current or future POSIX additions.
•UNIX Certification Is Formal — Only systems passing The Open Group's test suite can legally use the UNIX trademark.

What's Next

With the conceptual foundation established, the next page explores the practical heart of POSIX: the common POSIX system calls that form the core interface between applications and the operating system. We'll examine the major call categories, their semantics, and how they enable portable systems programming.

Page Complete

You now understand the origins, evolution, and structure of the POSIX standard. This foundation prepares you to work with POSIX system calls, evaluate portability requirements, and understand why POSIX remains central to modern operating system development.

1 / 5

Loading learning content...

Operating SystemsPOSIX Interface

POSIX Interface: The Portable Operating System Standard

LevelIntermediate

Duration90 mins

TopicPOSIX Interface

1 / 5

The POSIX Standard

The Portability Crisis That Shaped Modern Computing

What You Will Learn

The Unix Fragmentation Problem

To understand POSIX, we must first understand the chaos it was designed to resolve. The story begins with Unix itself—a revolutionary operating system that became too successful for its own good.

The Birth and Spread of Unix (1969-1980s)

But AT&T's licensing terms prohibited them from supporting Unix commercially. This created a critical vacuum: everyone wanted Unix, but no one had official responsibility for its evolution.

The AT&T Consent Decree

The Great Divergence

Without centralized control, Unix evolved in multiple directions simultaneously:

BSD Unix developed at the University of California, Berkeley, added virtual memory, TCP/IP networking, and the famous Berkeley sockets API
AT&T System V became the 'official' commercial Unix after AT&T was broken up in 1984
Xenix (Microsoft's Unix variant) targeted microcomputers
SunOS/Solaris, HP-UX, AIX, and IRIX each added proprietary extensions

The Unix Wars: Incompatibilities Between Major Variants
Feature	BSD Unix	AT&T System V	Impact on Portability
Terminal I/O	`ioctl()` with `sgttyb`	`ioctl()` with `termio`	Programs had to implement both interfaces
String Operations	`index()`, `rindex()`	`strchr()`, `strrchr()`	Different function names for identical operations
Networking	Berkeley sockets	STREAMS/TLI	Completely different network programming models
Job Control	Native support	Added later, differently	Shell scripts behaved unpredictably
Signal Handling	Reliable signals	Unreliable signals	Critical race conditions in portable code
Directory Reading	`readdir()` returns `direct`	`readdir()` returns `dirent`	Structure layout differences caused crashes

The Business Impact

This fragmentation created severe business problems:

Vendor Lock-in: Once you chose an HP system, your software was effectively tied to HP. Migration required major rewrites.
Duplicated Development Effort: Software vendors maintained separate codebases for each Unix variant, multiplying costs.
Stunted Market Growth: Potential customers hesitated to adopt Unix precisely because they feared choosing the 'wrong' variant.
Training Fragmentation: System administrators needed expertise in specific variants, reducing labor mobility.

The industry needed standardization—but who would create it, and how could competing vendors agree?

The Birth of POSIX

The /usr/group Initiative (1984)

IEEE Takes the Lead (1985)

Why 'POSIX' and Not 'Unix'?

The Federal Government Mandate (1988)

Vendors who wanted government contracts—a massive market—had to implement POSIX. Even Microsoft added a POSIX subsystem to Windows NT.

IEEE Std 1003.1-1988: The First POSIX Standard

The original POSIX.1 standard, officially IEEE Std 1003.1-1988, focused on the core operating system interface:

Process management (fork(), exec(), wait())
File and directory operations (open(), read(), write(), close())
User and group identity
Signals
Terminal interfaces
Basic I/O operations

This first standard was deliberately minimal—it specified what was common and stable across Unix implementations, deferring contentious areas for future work.

POSIX Design Principles

•Codify Existing Practice — POSIX standardized what already worked, rather than inventing new interfaces. If multiple implementations existed, the standard chose the most common approach or allowed both.
•Minimal Mandatory Requirements — The core standard was kept small to maximize implementability. Optional features were clearly marked as extensions.
•Source-Level Portability — POSIX targets source code compatibility, not binary compatibility. Programs should compile unchanged on different systems.
•C Language Binding — POSIX defines its interface in terms of C function calls and headers, establishing C as the systems programming language.
•Backward Compatibility — Each revision maintains compatibility with previous versions where possible, protecting existing software investments.

Evolution of the POSIX Family

The POSIX Family Tree

The IEEE 1003 family grew rapidly through the 1990s:

Major POSIX Standards and Their Scope
Standard	Name	Scope	Year
1003.1	System Interface	Core OS API, file I/O, process control	1988, 1990, 1996, 2001, 2008, 2017
1003.2	Shell and Utilities	Shell syntax, standard utilities (ls, grep, awk)	1992
1003.1b	Real-Time Extensions	Real-time signals, semaphores, shared memory, async I/O	1993
1003.1c	Threads	POSIX threads (pthreads) API	1995
1003.1d	Additional Real-Time	Sporadic server, typed memory	1999
1003.1g	Networking	Protocol-independent interfaces	2000
1003.1j	Advanced Real-Time	Barriers, spinlocks, reader-writer locks	2000

The Single UNIX Specification Merger

In 2001, a landmark merger consolidated multiple Unix standardization efforts:

POSIX (IEEE 1003.x)
The Single UNIX Specification (SUS) from The Open Group
ISO/IEC 9945 (the international version of POSIX)

The Modern Standard: POSIX.1-2017

The current version, IEEE Std 1003.1-2017 (also SUSv4 2018 edition), represents decades of refinement. It includes:

The base definitions (concepts, headers, and terminology)
System interfaces (the C language API)
Shell and utilities (command interpreter and tools)
Rationale (explanatory material, non-normative)

This specification runs to over 4,000 pages and defines more than 1,000 functions, 80+ utilities, and the complete shell command language.

Accessing the POSIX Standard

Key Additions Over Time

Each major revision added capabilities reflecting contemporary computing needs:

POSIX.1-1990: Formalized job control, symbolic links, and terminal handling
POSIX.1b-1993: Real-time extensions for deterministic scheduling and timing
POSIX.1c-1995: Thread support, enabling portable multi-threaded programming
POSIX.1-2001: Large file support, timestamping, additional security functions
POSIX.1-2008: Added openat() family, improved signal safety specifications
POSIX.1-2017: Refined specifications, deprecated obsolete functions, Unicode clarifications

Structure of the POSIX Specification

Understanding how POSIX is organized helps you navigate the specification and understand which guarantees apply to your code. The modern POSIX standard consists of four major volumes:

Volume 1: Base Definitions (XBD)

This volume establishes the foundation for everything else. It defines:

Terminology: Precise meanings for terms like 'process,' 'thread,' 'file descriptor,' and 'signal.'
Conformance Requirements: What an implementation must do to claim POSIX compliance.
Header Specifications: The contents of each standard header file (<unistd.h>, <fcntl.h>, <pthread.h>, etc.).
Locale Definitions: How internationalization works.
Environment Variables: Standard variables like PATH, HOME, LANG.
Regular Expressions: Two syntaxes—Basic Regular Expressions (BRE) and Extended Regular Expressions (ERE).
Directory Structure: Where standard files are located (/bin, /etc, /tmp, etc.).

Volume 2: System Interfaces (XSH)

This is the heart of POSIX for systems programmers. For each function, the specification provides:

Function Specification Components

•NAME — The function name and one-line description
•SYNOPSIS — Required headers and function prototype
•DESCRIPTION — Complete behavioral specification, including edge cases
•RETURN VALUE — What the function returns on success and failure
•ERRORS — All possible error conditions and corresponding errno values
•EXAMPLES — (Sometimes) Code demonstrating correct usage
•APPLICATION USAGE — Guidance for programmers using the function
•RATIONALE — Historical context and design decisions
•FUTURE DIRECTIONS — Planned changes or deprecations
•SEE ALSO — Related functions and concepts

POSIX open() Specification Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/* NAME */
open - open file relative to directory file descriptor
 
/* SYNOPSIS */
#include <fcntl.h>
 
int open(const char *path, int oflag, ...);
int openat(int fd, const char *path, int oflag, ...);
 
/* DESCRIPTION (abbreviated) */
The open() function shall establish the connection between a file
and a file descriptor. It shall create an open file description
that refers to a file and a file descriptor that refers to that
open file description.
 
/* RETURN VALUE */
Upon successful completion, these functions shall return a 
non-negative integer representing the file descriptor. Otherwise, 
-1 shall be returned and errno set to indicate the error.
 
/* ERRORS */
EACCES - Permission denied
EEXIST - O_CREAT and O_EXCL set, file exists
EINTR  - Signal received during open()
ENOENT - File does not exist and O_CREAT not set
ENOSPC - No space left on device (when creating)
... (over 20 possible error conditions)

Volume 3: Shell and Utilities (XCU)

This volume specifies the command-line environment:

Shell Command Language: Complete grammar and semantics for sh
Standard Utilities: Specifications for 160+ commands (ls, grep, awk, sed, make, etc.)
Utility Conventions: Standard option formats, exit codes, and behaviors

The shell specification is particularly detailed because portable shell scripts must behave identically across systems.

Volume 4: Rationale (XRAT)

This non-normative volume explains why decisions were made. It includes:

Historical context for interfaces
Discussions of alternatives considered
Guidance on implementation
Clarifications of ambiguous points

While not binding, the rationale is invaluable for understanding design intent.

Option Groups and Feature Test Macros

Understanding Option Groups

Each option group has a symbolic constant indicating its support status. The value of this constant tells you how the feature is implemented:

POSIX Option Group Values
Value	Meaning	Implication
`-1`	Feature not supported	Related functions may not exist or will fail with `ENOSYS`
`0`	Compile-time check unavailable	Must use `sysconf()` or `pathconf()` at runtime
`> 0`	Feature supported	All related functions are available

Major Option Groups

Some significantly impact portable programming:

_POSIX_THREADS: Thread support (pthreads)
_POSIX_REALTIME_SIGNALS: Real-time signal extensions
_POSIX_SEMAPHORES: POSIX semaphores
_POSIX_SHARED_MEMORY_OBJECTS: shm_open() and related functions
_POSIX_MEMORY_PROTECTION: Memory protection via mprotect()
_POSIX_ASYNCHRONOUS_IO: Asynchronous I/O operations
_POSIX_FSYNC: File synchronization guarantees

Feature Test Macros

POSIX uses feature test macros to control which declarations are visible. These prevent namespace pollution and enable strict conformance testing:

feature_test_macros.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/* Must be defined BEFORE any header includes */
 
/* Request POSIX.1-2008 features */
#define _POSIX_C_SOURCE 200809L
 
/* Or request full Single UNIX Specification */
#define _XOPEN_SOURCE 700
 
/* For GNU-specific extensions */
#define _GNU_SOURCE
 
/* For BSD-specific extensions */
#define _BSD_SOURCE
 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
 
int main(void) {
    /* Check if threads are supported */
    #if _POSIX_THREADS > 0
        printf("POSIX threads supported
");
    #elif _POSIX_THREADS == 0
        /* Runtime check needed */
        long threads = sysconf(_SC_THREADS);
        if (threads > 0) {
            printf("POSIX threads supported (runtime check)
");
        }
    #else
        printf("POSIX threads not supported
");
    #endif
    
    return 0;
}

Define Feature Test Macros First

Runtime Capability Checking

Because compile-time checks aren't always sufficient, POSIX provides runtime query functions:

sysconf(): Query system-wide configuration values
pathconf() / fpathconf(): Query path-specific limits
confstr(): Query configuration strings

These functions let your program adapt to the actual capabilities of the system it's running on:

runtime_checking.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <unistd.h>
#include <limits.h>
#include <errno.h>
 
void check_system_capabilities(void) {
    /* Query the maximum length of arguments to exec functions */
    long arg_max = sysconf(_SC_ARG_MAX);
    if (arg_max == -1) {
        perror("sysconf _SC_ARG_MAX");
    } else {
        printf("Maximum argument length: %ld bytes
", arg_max);
    }
    
    /* Query the number of processors */
    long nprocs = sysconf(_SC_NPROCESSORS_ONLN);
    if (nprocs > 0) {
        printf("Online processors: %ld
", nprocs);
    }
    
    /* Query path-specific limits */
    long name_max = pathconf("/", _PC_NAME_MAX);
    if (name_max == -1) {
        if (errno == 0) {
            printf("No limit on filename length
");
        } else {
            perror("pathconf _PC_NAME_MAX");
        }
    } else {
        printf("Maximum filename length: %ld
", name_max);
    }
    
    /* Query the POSIX version supported */
    long posix_version = sysconf(_SC_VERSION);
    printf("POSIX version: %ld
", posix_version);
    /* 200809L means POSIX.1-2008 */
}

Conformance and Compliance Levels

POSIX defines precise language for discussing standards compliance. Understanding these terms helps you evaluate system capabilities and write truly portable code.

Normative Language

The POSIX standard uses specific words with precise meanings:

POSIX Normative Terminology
Term	Meaning	Example
shall	Absolute requirement	`open()` shall return a file descriptor
shall not	Absolute prohibition	A process shall not access freed memory
should	Recommended but not required	Implementations should minimize latency
may	Optional feature	The system may support asynchronous I/O
undefined	No requirements, behavior unpredictable	Reading uninitialized memory is undefined
unspecified	Implementation must document behavior	Scheduling order among equal-priority processes
implementation-defined	Implementation chooses, must document	Maximum number of open file descriptors

Conformance Levels

Implementations can claim different levels of POSIX conformance:

POSIX Conformant: Implements the mandatory portions of POSIX.1
POSIX Compliant: Implements mandatory portions plus one or more option groups
XSI Conformant: Implements the full X/Open System Interfaces extension (includes internationalization, additional utilities, and features from traditional Unix)
UNIX Certified: Has passed The Open Group's official certification test suite

The UNIX® Trademark

Only systems that pass The Open Group's certification can use the UNIX® trademark. This involves:

Running a comprehensive test suite (over 5,000 tests)
Documenting all implementation-defined behavior
Paying certification fees
Regular recertification

Certified systems include macOS, Solaris, HP-UX, and AIX. Linux, despite being highly POSIX-compatible, is not certified as UNIX (primarily due to cost and the philosophical stance of the community).

Linux and POSIX Compliance

The POSIX Namespace

POSIX carefully manages the namespace—the names available for use by implementations, applications, and the standard itself. This prevents collisions between your code and system libraries.

Reserved Namespaces

POSIX reserves certain naming patterns for its own use:

Names Reserved by POSIX

•Names starting with underscore + uppercase — _Uppercase, __anything: Reserved for the implementation (compiler, library)
•Names starting with double underscore — __name: Reserved regardless of following character
•Names ending with _t — Reserved for type definitions (e.g., size_t, pid_t)
•Names starting with E + digit or uppercase — Reserved for additional error numbers (e.g., EAGAIN)
•Names starting with SIG + uppercase — Reserved for signal names (e.g., SIGKILL)
•Names starting with is or to + lowercase — Reserved for character testing/conversion (e.g., isdigit, toupper)
•Names starting with str, mem, or wcs — Reserved for string/memory/wide-string functions

Why This Matters

Respecting reserved namespaces prevents subtle, hard-to-debug errors:

namespace_violations.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/* DON'T DO THIS - These names are reserved */
 
typedef int size_t;          /* WRONG: _t suffix reserved */
#define EINVALID 500         /* WRONG: E + uppercase reserved */
void strappend(char *s);     /* WRONG: str + lowercase reserved */
int _Private_function(void); /* WRONG: _ + uppercase reserved */
 
/* DO THIS INSTEAD */
 
typedef int my_size;          /* OK: no reserved suffix */
#define MY_ERR_INVALID 500    /* OK: different prefix */
void my_strappend(char *s);   /* OK: unique prefix */
int private_function(void);   /* OK: no leading underscore */
 
/* Project-specific prefixes prevent ALL conflicts */
typedef int proj_size;
#define PROJ_ERR_INVALID 500
void proj_strappend(char *s);

Practical Advice

Summary: The POSIX Standard

We have covered the complete foundation of POSIX—from its historical origins through its current structure. Let's consolidate the essential knowledge:

Key Takeaways

•POSIX Solved Fragmentation — Without POSIX, the Unix ecosystem would have fractured into incompatible islands. The standard enabled a portable software industry.
•POSIX Defines Interfaces, Not Implementations — Any operating system can implement POSIX interfaces. This separates the API contract from specific implementations.
•The Standard Has Four Volumes — Base Definitions (XBD), System Interfaces (XSH), Shell and Utilities (XCU), and Rationale (XRAT) together form the complete specification.
•Option Groups Handle Variability — Not all features are mandatory. Feature test macros and runtime queries let code adapt to available capabilities.
•Normative Language Is Precise — Words like 'shall,' 'should,' and 'may' have specific meanings that affect how implementations and applications must behave.
•Namespace Management Prevents Conflicts — Reserved naming patterns ensure that applications don't collide with current or future POSIX additions.
•UNIX Certification Is Formal — Only systems passing The Open Group's test suite can legally use the UNIX trademark.

What's Next

Page Complete

1 / 5