The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.
A newer edition of this document exists here

D. Portability Considerations (Informative)

This section contains information to satisfy various international requirements:

D.1 User Requirements

This section describes the user requirements that were perceived by the developers of IEEE Std 1003.1-2001. The primary source for these requirements was an analysis of historical practice in widespread use, as typified by the base documents listed in Scope.

IEEE Std 1003.1-2001 addresses the needs of users requiring open systems solutions for source code portability of applications. It currently addresses users requiring open systems solutions for source-code portability of applications involving multi-programming and process management (creating processes, signaling, and so on); access to files and directories in a hierarchy of file systems (opening, reading, writing, deleting files, and so on); access to asynchronous communications ports and other special devices; access to information about other users of the system; facilities supporting applications requiring bounded (realtime) response.

The following users are identified for IEEE Std 1003.1-2001:

An acknowledged restriction on applicable users is that they are limited to the group of individuals who are familiar with the style of interaction characteristic of historically-derived systems based on one of the UNIX operating systems (as opposed to other historical systems with different models, such as MS/DOS, Macintosh, VMS, MVS, and so on). Typical users would include program developers, engineers, or general-purpose time-sharing users.

The requirements of users of IEEE Std 1003.1-2001 can be summarized as a single goal: application source portability. The requirements of the user are stated in terms of the requirements of portability of applications. This in turn becomes a requirement for a standardized set of syntax and semantics for operations commonly found on many operating systems.

The following sections list the perceived requirements for application portability.

D.1.1 Configuration Interrogation

An application must be able to determine whether and how certain optional features are provided and to identify the system upon which it is running, so that it may appropriately adapt to its environment.

Applications must have sufficient information to adapt to varying behaviors of the system.

D.1.2 Process Management

An application must be able to manage itself, either as a single process or as multiple processes. Applications must be able to manage other processes when appropriate.

Applications must be able to identify, control, create, and delete processes, and there must be communication of information between processes and to and from the system.

Applications must be able to use multiple flows of control with a process (threads) and synchronize operations between these flows of control.

D.1.3 Access to Data

Applications must be able to operate on the data stored on the system, access it, and transmit it to other applications. Information must have protection from unauthorized or accidental access or modification.

D.1.4 Access to the Environment

Applications must be able to access the external environment to communicate their input and results.

D.1.5 Access to Determinism and Performance Enhancements

Applications must have sufficient control of resource allocation to ensure the timeliness of interactions with external objects.

D.1.6 Operating System-Dependent Profile

The capabilities of the operating system may make certain optional characteristics of the base language in effect no longer optional, and this should be specified.

D.1.7 I/O Interaction

The interaction between the C language I/O subsystem ( stdio) and the I/O subsystem of IEEE Std 1003.1-2001 must be specified.

D.1.8 Internationalization Interaction

The effects of the environment of IEEE Std 1003.1-2001 on the internationalization facilities of the C language must be specified.

D.1.9 C-Language Extensions

Certain functions in the C language must be extended to support the additional capabilities provided by IEEE Std 1003.1-2001.

D.1.10 Command Language

Users should be able to define procedures that combine simple tools and/or applications into higher-level components that perform to the specific needs of the user. The user should be able to store, recall, use, and modify these procedures. These procedures should employ a powerful command language that is used for recurring tasks in conforming applications (scripts) in the same way that it is used interactively to accomplish one-time tasks. The language and the utilities that it uses must be consistent between systems to reduce errors and retraining.

D.1.11 Interactive Facilities

Use the system to accomplish individual tasks at an interactive terminal. The interface should be consistent, intuitive, and offer usability enhancements to increase the productivity of terminal users, reduce errors, and minimize retraining costs. Online documentation or usage assistance should be available.

D.1.12 Accomplish Multiple Tasks Simultaneously

Access applications and interactive facilities from a single terminal without requiring serial execution: switch between multiple interactive tasks; schedule one-time or periodic background work; display the status of all work in progress or scheduled; influence the priority scheduling of work, when authorized.

D.1.13 Complex Data Manipulation

Manipulate data in files in complex ways: sort, merge, compare, translate, edit, format, pattern match, select subsets (strings, columns, fields, rows, and so on). These facilities should be available to both conforming applications and interactive users.

D.1.14 File Hierarchy Manipulation

Create, delete, move/rename, copy, backup/archive, and display files and directories. These facilities should be available to both conforming applications and interactive users.

D.1.15 Locale Configuration

Customize applications and interactive sessions for the cultural and language conventions of the user. Employ a wide variety of standard character encodings. These facilities should be available to both conforming applications and interactive users.

D.1.16 Inter-User Communication

Send messages or transfer files to other users on the same system or other systems on a network. These facilities should be available to both conforming applications and interactive users.

D.1.17 System Environment

Display information about the status of the system (activities of users and their interactive and background work, file system utilization, system time, configuration, and presence of optional facilities) and the environment of the user (terminal characteristics, and so on). Inform the system operator/administrator of problems. Control access to user files and other resources.

D.1.18 Printing

Output files on a variety of output device classes, accessing devices on local or network-connected systems. Control (or influence) the formatting, priority scheduling, and output distribution of work. These facilities should be available to both conforming applications and interactive users.

D.1.19 Software Development

Develop (create and manage source files, compile/interpret, debug) portable open systems applications and package them for distribution to, and updating of, other systems.

D.2 Portability Capabilities

This section describes the significant portability capabilities of IEEE Std 1003.1-2001 and indicates how the user requirements listed in User Requirements are addressed. The capabilities are listed in the same format as the preceding user requirements; they are summarized below:

D.2.1 Configuration Interrogation

The uname() operation provides basic identification of the system. The sysconf(), pathconf(), and fpathconf() functions and the getconf utility provide means to interrogate the implementation to determine how to adapt to the environment in which it is running. These values can be either static (indicating that all instances of the implementation have the same value) or dynamic (indicating that different instances of the implementation have the different values, or that the value may vary for other reasons, such as reconfiguration).

Unsatisfied Requirements

None directly. However, as new areas are added, there will be a need for additional capability in this area.

D.2.2 Process Management

The fork(), exec family, posix_spawn(), and posix_spawnp() functions provide for the creation of new processes or the insertion of new applications into existing processes. The _Exit(), _exit(), exit(), and abort() functions allow for the termination of a process by itself. The wait() and waitpid() functions allow one process to deal with the termination of another.

The times() function allows for basic measurement of times used by a process. Various functions, including fstat(), getegid(), geteuid(), getgid(), getgrgid(), getgrnam(), getlogin(), getpid(), getppid(), getpwnam(), getpwuid(), getuid(), lstat(), and stat(), provide for access to the identifiers of processes and the identifiers and names of owners of processes (and files).

The various functions operating on environment variables provide for communication of information (primarily user-configurable defaults) from a parent to child processes.

The operations on the current working directory control and interrogate the directory from which relative filename searches start. The umask() function controls the default protections applied to files created by the process.

The alarm(), pause(), sleep(), ualarm(), and usleep() operations allow the process to suspend until a timer has expired or to be notified when a period of time has elapsed. The time() operation interrogates the current time and date.

The signal mechanism provides for communication of events either from other processes or from the environment to the application, and the means for the application to control the effect of these events. The mechanism provides for external termination of a process and for a process to suspend until an event occurs. The mechanism also provides for a value to be associated with an event.

Job control provides a means to group processes and control them as groups, and to control their access to the function between the user and the system (the "controlling terminal"). It also provides the means to suspend and resume processes.

The Process Scheduling option provides control of the scheduling and priority of a process.

The Message Passing option provides a means for interprocess communication involving small amounts of data.

The Memory Management facilities provide control of memory resources and for the sharing of memory. This functionality is mandatory on XSI-conformant systems.

The Threads facilities provide multiple flows of control with a process (threads), synchronization between threads, association of data with threads, and controlled cancellation of threads.

The XSI interprocess communications functionality provide an alternate set of facilities to manipulate semaphores, message queues, and shared memory. These are provided on XSI-conformant systems to support conforming applications developed to run on UNIX systems.

D.2.3 Access to Data

The open(), close(), fclose(), fopen(), and pipe() functions provide for access to files and data. Such files may be regular files, interprocess data channels (pipes), or devices. Additional types of objects in the file system are permitted and are being contemplated for standardization.

The access(), chmod(), chown(), dup(), dup2(), fchmod(), fcntl(), fstat(), ftruncate(), lstat(), readlink(), realpath(), stat(), and utime() functions allow for control and interrogation of file and file-related objects (including symbolic links), and their ownership, protections, and timestamps.

The fgetc(), fputc(), fread(), fseek(), fsetpos(), fwrite(), getc(), getchar(), lseek(), putchar(), putc(), read(), and write() functions provide for data transfer from the application to files (in all their forms).

The closedir(), link(), mkdir(), opendir(), readdir(), rename(), rmdir(), rewinddir(), and unlink() functions provide for a complete set of operations on directories. Directories can arbitrarily contain other directories, and a single file can be mentioned in more than one directory.

The file-locking mechanism provides for advisory locking (protection during transactions) of ranges of bytes (in effect, records) in a file.

The confstr(), fpathconf(), pathconf(), and sysconf() functions provide for enquiry as to the behavior of the system where variability is permitted.

The Synchronized Input and Output option provides for assured commitment of data to media.

The Asynchronous Input and Output option provides for initiation and control of asynchronous data transfers.

D.2.4 Access to the Environment

The operations and types in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 11, General Terminal Interface are provided for access to asynchronous serial devices. The primary intended use for these is the controlling terminal for the application (the interaction point between the user and the system). They are general enough to be used to control any asynchronous serial device. The functions are also general enough to be used with many other device types as a user interface when some emulation is provided.

Less detailed access is provided for other device types, but in many instances an application need not know whether an object in the file system is a device or a regular file to operate correctly.

Unsatisfied Requirements

Detailed control of common device classes, specifically magnetic tape, is not provided.

D.2.5 Bounded (Realtime) Response

The Realtime Signals Extension provides queued signals and the prioritization of the handling of signals. The SCHED_FIFO, SCHED_SPORADIC, and SCHED_RR scheduling policies provide control over processor allocation. The Semaphores option provides high-performance synchronization. The Memory Management functions provide memory locking for control of memory allocation, file mapping for high-performance, and shared memory for high-performance interprocess communication. The Message Passing option provides for interprocess communication without being dependent on shared memory.

The Timers option provides a high resolution function called nanosleep() with a finer resolution than the sleep() function.

The Typed Memory Objects option, the Monotonic Clock option, and the Timeouts option provide further facilities for applications to use to obtain predictable bounded response.

D.2.6 Operating System-Dependent Profile

IEEE Std 1003.1-2001 makes no distinction between text and binary files. The values of EXIT_SUCCESS and EXIT_FAILURE are further defined.

Unsatisfied Requirements

None known, but the ISO C standard may contain some additional options that could be specified.

D.2.7 I/O Interaction

IEEE Std 1003.1-2001 defines how each of the ISO C standard stdio functions interact with the POSIX.1 operations, typically specifying the behavior in terms of POSIX.1 operations.

Unsatisfied Requirements

None.

D.2.8 Internationalization Interaction

The IEEE Std 1003.1-2001 environment operations provide a means to define the environment for setlocale() and time functions such as ctime(). The tzset() function is provided to set time conversion information.

The nl_langinfo() function is provided as an XSI extension to query locale-specific cultural settings.

Unsatisfied Requirements

None.

D.2.9 C-Language Extensions

The setjmp() and longjmp() functions are not defined to be cognizant of the signal masks defined for POSIX.1. The sigsetjmp() and siglongjmp() functions are provided to fill this gap.

The _setjmp() and _longjmp() functions are provided as XSI extensions to support historic practice.

Unsatisfied Requirements

None.

D.2.10 Command Language

The shell command language, as described in the Shell and Utilities volume of IEEE Std 1003.1-2001, Chapter 2, Shell Command Language, is a common language useful in batch scripts, through an API to high-level languages (for the C-Language Binding option, system() and popen()) and through an interactive terminal (see the sh utility). The shell language has many of the characteristics of a high-level language, but it has been designed to be more suitable for user terminal entry and includes interactive debugging facilities. Through the use of pipelining, many complex commands can be constructed from combinations of data filters and other common components. Shell scripts can be created, stored, recalled, and modified by the user with simple editors.

In addition to the basic shell language, the following utilities offer features that simplify and enhance programmatic access to the utilities and provide features normally found only in high-level languages: basename, bc, command, dirname, echo, env, expr, false, printf, read, sleep, tee, test, CONVERSION ERROR (.Cm) time *,1 true, wait, xargs, and all of the special built-in utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.14, Special Built-In Utilities.

Unsatisfied Requirements

None.

D.2.11 Interactive Facilities

The utilities offer a common style of command-line interface through conformance to the Utility Syntax Guidelines (see the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines) and the common utility defaults (see the Shell and Utilities volume of IEEE Std 1003.1-2001, Section 1.11, Utility Description Defaults). The sh utility offers an interactive command-line history and editing facility. The following utilities in the User Portability Utilities option have been customized for interactive use: alias, ex, fc, mailx, more, talk, vi, unalias, and write; the man utility offers online access to system documentation.

Unsatisfied Requirements

The command line interface to individual utilities is as intuitive and consistent as historical practice allows. Work underway based on graphical user interfaces may be more suitable for novice or occasional users of the system.

D.2.12 Accomplish Multiple Tasks Simultaneously

The shell command language offers background processing through the asynchronous list command form; see the Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.9, Shell Commands. The nohup utility makes background processing more robust and usable. The kill utility can terminate background jobs. When the User Portability Utilities option is supported, the following utilities allow manipulation of jobs: bg, fg, and jobs. Also, if the User Portability Utilities option is supported, the following can support periodic job scheduling, control, and display: at, batch, crontab, nice, ps, and renice.

Unsatisfied Requirements

Terminals with multiple windows may be more suitable for some multi-tasking interactive uses than the job control approach in IEEE Std 1003.1-2001. See the comments on graphical user interfaces in Interactive Facilities . The nice and renice utilities do not necessarily take advantage of complex system scheduling algorithms that are supported by the realtime options within IEEE Std 1003.1-2001.

D.2.13 Complex Data Manipulation

The following utilities address user requirements in this area: asa, awk, bc, cmp, comm, csplit*, cut, dd, diff, ed, ex*, expand*, expr, find, fold, grep, head, join, od, paste, pr, printf, sed, sort, split*, tabs*, tail, tr, unexpand*, uniq, uudecode*, uuencode*, and wc.

Unsatisfied Requirements

Sophisticated text formatting utilities, such as troff or TeX, are not included. Standards work in the area of SGML may satisfy this.

D.2.14 File Hierarchy Manipulation

The following utilities address user requirements in this area: basename, cd, chgrp, chmod, chown, cksum, cp, dd, df*, diff, dirname, du*, find, ls, ln, mkdir, mkfifo, mv, patch*, pathchk, pax, pwd, rm, rmdir, test, and touch.

Unsatisfied Requirements

Some graphical user interfaces offer more intuitive file manager components that allow file manipulation through the use of icons for novice users.

D.2.15 Locale Configuration

The standard utilities are affected by the various LC_ variables to achieve locale-dependent operation: character classification, collation sequences, regular expressions and shell pattern matching, date and time formats, numeric formatting, and monetary formatting. When the POSIX2_LOCALEDEF option is supported, applications can provide their own locale definition files. The following utilities address user requirements in this area: date, ed, ex*, find, grep, locale, localedef, more*, sed, sh, sort, tr, uniq, and vi*.

The iconv(), iconv_close(), and iconv_open() functions are available to allow an application to convert character data between supported character sets.

The gencat utility and the catopen(), catclose(), and catgets() functions for message catalog manipulation are available on XSI-conformant systems.

Unsatisfied Requirements

Some aspects of multi-byte character and state-encoded character encodings have not yet been addressed. The C-language functions, such as getopt(), are generally limited to single-byte characters. The effect of the LC_MESSAGES variable on message formats is only suggested at this time.

D.2.16 Inter-User Communication

The following utilities address user requirements in this area: cksum, mailx*, mesg*, patch*, pax, talk*, uudecode*, uuencode*, who*, and write*.

The historical UUCP utilities are included on XSI-conformant systems.

Unsatisfied Requirements

None.

D.2.17 System Environment

The following utilities address user requirements in this area: chgrp, chmod, chown, df*, du*, env, getconf, id, logger, logname, mesg*, newgrp*, ps*, stty, tput*, tty, umask, uname, and who*.

The closelog(), openlog(), setlogmask(), and syslog() functions provide System Logging facilities on XSI-conformant systems; these are analogous to the logger utility.

Unsatisfied Requirements

None.

D.2.18 Printing

The following utilities address user requirements in this area: pr and lp.

Unsatisfied Requirements

There are no features to control the formatting or scheduling of the print jobs.

D.2.19 Software Development

The following utilities address user requirements in this area: ar, asa, awk, c99, ctags*, fort77, getconf, getopts, lex, localedef, make, nm*, od, patch*, pax, strings*, strip, time*, and yacc.

The system(), popen(), pclose(), regcomp(), regexec(), regerror(), regfree(), fnmatch(), getopt(), glob(), globfree(), wordexp(), and wordfree() functions allow C-language programmers to access some of the interfaces used by the utilities, such as argument processing, regular expressions, and pattern matching.

The SCCS source-code control system utilities are available on systems supporting the XSI Development option.

Unsatisfied Requirements

There are no language-specific development tools related to languages other than C and FORTRAN. The C tools are more complete and varied than the FORTRAN tools. There is no data dictionary or other CASE-like development tools.

D.2.20 Future Growth

It is arguable whether or not all functionality to support applications is potentially within the scope of IEEE Std 1003.1-2001. As a simple matter of practicality, it cannot be. Areas such as graphics, application domain-specific functionality, windowing, and so on, should be in unique standards. As such, they are properly "Unsatisfied Requirements" in terms of providing fully conforming applications, but ones which are outside the scope of IEEE Std 1003.1-2001.

However, as the standards evolve, certain functionality once considered "exotic" enough to be part of a separate standard become common enough to be included in a core standard such as this. Realtime and networking, for example, have both moved from separate standards (with much difficult cross-referencing) into IEEE Std 1003.1 over time, and although no specific areas have been identified for inclusion in future revisions, such inclusions seem likely.

D.3 Profiling Considerations

This section offers guidance to writers of profiles on how the configurable options, limits, and optional behavior of IEEE Std 1003.1-2001 should be cited in profiles. Profile writers should consult the general guidance in POSIX.0 when writing POSIX Standardized Profiles.

The information in this section is an inclusive list of features that should be considered by profile writers. Subsetting of IEEE Std 1003.1-2001 should follow the Base Definitions volume of IEEE Std 1003.1-2001, Section 2.1.5.1, Subprofiling Considerations. A set of profiling options is described in Subprofiling Considerations (Informative).

D.3.1 Configuration Options

There are two set of options suggested by IEEE Std 1003.1-2001: those for POSIX-conforming systems and those for X/Open System Interface (XSI) conformance. The requirements for XSI conformance are documented in the Base Definitions volume of IEEE Std 1003.1-2001 and not discussed further here, as they superset the POSIX conformance requirements.

D.3.2 Configuration Options (Shell and Utilities)

There are three broad optional configurations for the Shell and Utilities volume of IEEE Std 1003.1-2001: basic execution system, development system, and user portability interactive system. The options to support these, and other minor configuration options, are listed in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 2, Conformance. Profile writers should consult the following list and the comments concerning user requirements addressed by various components in Portability Capabilities.

POSIX2_UPE
The system supports the User Portability Utilities option.

This option is a requirement for a user portability interactive system. It is required frequently except for those systems, such as embedded realtime or dedicated application systems, that support little or no interactive time-sharing work by users or operators. XSI-conformant systems support this option.

POSIX2_SW_DEV
The system supports the Software Development Utilities option.

This option is required by many systems, even those in which actual software development does not occur. The make utility, in particular, is required by many application software packages as they are installed onto the system. If POSIX2_C_DEV is supported, POSIX2_SW_DEV is almost a mandatory requirement because of ar and make.

POSIX2_C_BIND
The system supports the C-Language Bindings option.

This option is required on some implementations developing complex C applications or on any system installing C applications in source form that require the functions in this option. The system() and popen() functions, in particular, are widely used by applications; the others are rather more specialized.

POSIX2_C_DEV
The system supports the C-Language Development Utilities option.

This option is required by many systems, even those in which actual C-language software development does not occur. The c99 utility, in particular, is required by many application software packages as they are installed onto the system. The lex and yacc utilities are used less frequently.

POSIX2_FORT_DEV
The system supports the FORTRAN Development Utilities option

As with C, this option is needed on any system developing or installing FORTRAN applications in source form.

POSIX2_FORT_RUN
The system supports the FORTRAN Runtime Utilities option.

This option is required for some FORTRAN applications that need the asa utility to convert Hollerith printing statement output. It is unknown how frequently this occurs.

POSIX2_LOCALEDEF
The system supports the creation of locales.

This option is needed if applications require their own customized locale definitions to operate. It is presently unknown whether many applications are dependent on this. However, the option is virtually mandatory for systems in which internationalized applications are developed.

XSI-conformant systems support this option.

POSIX2_PBS
The system supports the Batch Environment Services and Utilities option.
POSIX2_PBS_ACCOUNTING
The system supports the optional feature of accounting within the Batch Environment Services and Utilities option. It will be required in servers that implement the optional feature of accounting.
POSIX2_PBS_CHECKPOINT
The system supports the optional feature of checkpoint/restart within the Batch Environment Services and Utilities option.
POSIX2_PBS_LOCATE
The system supports the optional feature of locating batch jobs within the Batch Environment Services and Utilities option.
POSIX2_PBS_MESSAGE
The system supports the optional feature of sending messages to batch jobs within the Batch Environment Services and Utilities option.
POSIX2_PBS_TRACK
The system supports the optional feature of tracking batch jobs within the Batch Environment Services and Utilities option.
POSIX2_CHAR_TERM
The system supports at least one terminal type capable of all operations described in IEEE Std 1003.1-2001.

On systems with POSIX2_UPE, this option is almost always required. It was developed solely to allow certain specialized vendors and user applications to bypass the requirement for general-purpose asynchronous terminal support. For example, an application and system that was suitable for block-mode terminals, such as IBM 3270s, would not need this option.

XSI-conformant systems support this option.

D.3.3 Configurable Limits

Very few of the limits need to be increased for profiles. No profile can cite lower values.

{POSIX2_BC_BASE_MAX}
{POSIX2_BC_DIM_MAX}
{POSIX2_BC_SCALE_MAX}
{POSIX2_BC_STRING_MAX}
No increase is anticipated for any of these bc values, except for very specialized applications involving huge numbers.
{POSIX2_COLL_WEIGHTS_MAX}
Some natural languages with complex collation requirements require an increase from the default 2 to 4; no higher numbers are anticipated.
{POSIX2_EXPR_NEST_MAX}
No increase is anticipated.
{POSIX2_LINE_MAX}
This number is much larger than most historical applications have been able to use. At some future time, applications may be rewritten to take advantage of even larger values.
{POSIX2_RE_DUP_MAX}
No increase is anticipated.
{POSIX2_VERSION}
This is actually not a limit, but a standard version stamp. Generally, a profile should specify the Shell and Utilities volume of IEEE Std 1003.1-2001, Chapter 2, Shell Command Language by name in the normative references section, not this value.

D.3.4 Configuration Options (System Interfaces)

{NGROUPS_MAX}
A non-zero value indicates that the implementation supports supplementary groups.

This option is needed where there is a large amount of shared use of files, but where a certain amount of protection is needed. Many profiles2 are known to require this option; it should only be required if needed, but it should never be prohibited.

_POSIX_ADVISORY_INFO
The system provides advisory information for file management.

This option allows the application to specify advisory information that can be used to achieve better or even deterministic response time in file manager or input and output operations.

_POSIX_ASYNCHRONOUS_IO
The system provides concurrent process execution and input and output transfers.

This option was created to support historical systems that did not provide the feature. It should only be required if needed, but it should never be prohibited.

_POSIX_BARRIERS
The system supports barrier synchronization.

This option was created to allow efficient synchronization of multiple parallel threads in multi-processor systems in which the operation is supported in part by the hardware architecture.

_POSIX_CHOWN_RESTRICTED
The system restricts the right to "give away" files to other users.

This option should be carefully investigated before it is required. Some applications expect that they can change the ownership of files in this way. It is provided where either security or system account requirements cause this ability to be a problem. It is also known to be specified in many profiles.

_POSIX_CLOCK_SELECTION
The system supports the Clock Selection option.

This option allows applications to request a high resolution sleep in order to suspend a thread during a relative time interval, or until an absolute time value, using the desired clock. It also allows the application to select the clock used in a pthread_cond_timedwait() function call.

_POSIX_CPUTIME
The system supports the Process CPU-Time Clocks option.

This option allows applications to use a new clock that measures the execution times of processes or threads, and the possibility to create timers based upon these clocks, for runtime detection (and treatment) of execution time overruns.

_POSIX_FSYNC
The system supports file synchronization requests.

This option was created to support historical systems that did not provide the feature. Applications that are expecting guaranteed completion of their input and output operations should require the _POSIX_SYNC_IO option. This option should never be prohibited.

XSI-conformant systems support this option.

_POSIX_IPV6
The system supports facilities related to Internet Protocol Version 6 (IPv6).

This option was created to allow systems to transition to IPv6.

_POSIX_JOB_CONTROL
Job control facilities are mandatory in IEEE Std 1003.1-2001.

The option was created primarily to support historical systems that did not provide the feature. Many existing profiles now require it; it should only be required if needed, but it should never be prohibited. Most applications that use it can run when it is not present, although with a degraded level of user convenience.

_POSIX_MAPPED_FILES
The system supports the mapping of regular files into the process address space.

XSI-conformant systems support this option.

Both this option and the Shared Memory Objects option provide shared access to memory objects in the process address space. The functions defined under this option provide the functionality of existing practice for mapping regular files. This functionality was deemed unnecessary, if not inappropriate, for embedded systems applications and, hence, is provided under this option. It should only be required if needed, but it should never be prohibited.

_POSIX_MEMLOCK
The system supports the locking of the address space.

This option was created to support historical systems that did not provide the feature. It should only be required if needed, but it should never be prohibited.

_POSIX_MEMLOCK_RANGE
The system supports the locking of specific ranges of the address space.

For applications that have well-defined sections that need to be locked and others that do not, IEEE Std 1003.1-2001 supports an optional set of functions to lock or unlock a range of process addresses. The following are two reasons for having a means to lock down a specific range:

  1. An asynchronous event handler function that must respond to external events in a deterministic manner such that page faults cannot be tolerated

  2. An input/output "buffer" area that is the target for direct-to-process I/O, and the overhead of implicit locking and unlocking for each I/O call cannot be tolerated

It should only be required if needed, but it should never be prohibited.

_POSIX_MEMORY_PROTECTION
The system supports memory protection.

XSI-conformant systems support this option.

The provision of this option typically imposes additional hardware requirements. It should never be prohibited.

_POSIX_PRIORITIZED_IO
The system provides prioritization for input and output operations.

The use of this option may interfere with the ability of the system to optimize input and output throughput. It should only be required if needed, but it should never be prohibited.

_POSIX_MESSAGE_PASSING
The system supports the passing of messages between processes.

This option was created to support historical systems that did not provide the feature. The functionality adds a high-performance XSI interprocess communication facility for local communication. It should only be required if needed, but it should never be prohibited.

_POSIX_MONOTONIC_CLOCK
The system supports the Monotonic Clock option.

This option allows realtime applications to rely on a monotonically increasing clock that does not jump backwards, and whose value does not change except for the regular ticking of the clock.

_POSIX_PRIORITY_SCHEDULING
The system provides priority-based process scheduling.

Support of this option provides predictable scheduling behavior, allowing applications to determine the order in which processes that are ready to run are granted access to a processor. It should only be required if needed, but it should never be prohibited.

_POSIX_REALTIME_SIGNALS
The system provides prioritized, queued signals with associated data values.

This option was created to support historical systems that did not provide the features. It should only be required if needed, but it should never be prohibited.

_POSIX_REGEXP
Support for regular expression facilities is mandatory in IEEE Std 1003.1-2001.
_POSIX_SAVED_IDS
Support for this feature is mandatory in IEEE Std 1003.1-2001.

Certain classes of applications rely on it for proper operation, and there is no alternative short of giving the application root privileges on most implementations that did not provide _POSIX_SAVED_IDS.

_POSIX_SEMAPHORES
The system provides counting semaphores.

This option was created to support historical systems that did not provide the feature. It should only be required if needed, but it should never be prohibited.

_POSIX_SHARED_MEMORY_OBJECTS
The system supports the mapping of shared memory objects into the process address space.

Both this option and the Memory Mapped Files option provide shared access to memory objects in the process address space. The functions defined under this option provide the functionality of existing practice for shared memory objects. This functionality was deemed appropriate for embedded systems applications and, hence, is provided under this option. It should only be required if needed, but it should never be prohibited.

_POSIX_SHELL
Support for the sh utility command line interpreter is mandatory in IEEE Std 1003.1-2001.
_POSIX_SPAWN
The system supports the spawn option.

This option provides applications with an efficient mechanism to spawn execution of a new process.

_POSIX_SPINLOCKS
The system supports spin locks.

This option was created to support a simple and efficient synchronization mechanism for threads executing in multi-processor systems.

_POSIX_SPORADIC_SERVER
The system supports the sporadic server scheduling policy.

This option provides applications with a new scheduling policy for scheduling aperiodic processes or threads in hard realtime applications.

_POSIX_SYNCHRONIZED_IO
The system supports guaranteed file synchronization.

This option was created to support historical systems that did not provide the feature. Applications that are expecting guaranteed completion of their input and output operations should require this option, rather than the File Synchronization option. It should only be required if needed, but it should never be prohibited.

_POSIX_THREADS
The system supports multiple threads of control within a single process.

This option was created to support historical systems that did not provide the feature. Applications written assuming a multi-threaded environment would be expected to require this option. It should only be required if needed, but it should never be prohibited.

XSI-conformant systems support this option.

_POSIX_THREAD_ATTR_STACKADDR
The system supports specification of the stack address for a created thread.

Applications may take advantage of support of this option for performance benefits, but dependence on this feature should be minimized. This option should never be prohibited.

XSI-conformant systems support this option.

_POSIX_THREAD_ATTR_STACKSIZE
The system supports specification of the stack size for a created thread.

Applications may require this option in order to ensure proper execution, but such usage limits portability and dependence on this feature should be minimized. It should only be required if needed, but it should never be prohibited.

XSI-conformant systems support this option.

_POSIX_THREAD_PRIORITY_SCHEDULING
The system provides priority-based thread scheduling.

Support of this option provides predictable scheduling behavior, allowing applications to determine the order in which threads that are ready to run are granted access to a processor. It should only be required if needed, but it should never be prohibited.

_POSIX_THREAD_PRIO_INHERIT
The system provides mutual-exclusion operations with priority inheritance.

Support of this option provides predictable scheduling behavior, allowing applications to determine the order in which threads that are ready to run are granted access to a processor. It should only be required if needed, but it should never be prohibited.

_POSIX_THREAD_PRIO_PROTECT
The system supports a priority ceiling emulation protocol for mutual-exclusion operations.

Support of this option provides predictable scheduling behavior, allowing applications to determine the order in which threads that are ready to run are granted access to a processor. It should only be required if needed, but it should never be prohibited.

_POSIX_THREAD_PROCESS_SHARED
The system provides shared access among multiple processes to synchronization objects.

This option was created to support historical systems that did not provide the feature. It should only be required if needed, but it should never be prohibited.

XSI-conformant systems support this option.

_POSIX_THREAD_SAFE_FUNCTIONS
The system provides thread-safe versions of all of the POSIX.1 functions.

This option is required if the Threads option is supported. This is a separate option because thread-safe functions are useful in implementations providing other mechanisms for concurrency. It should only be required if needed, but it should never be prohibited.

XSI-conformant systems support this option.

_POSIX_THREAD_SPORADIC_SERVER
The system supports the thread sporadic server scheduling policy.

Support for this option provides applications with a new scheduling policy for scheduling aperiodic threads in hard realtime applications.

_POSIX_TIMEOUTS
The system provides timeouts for some blocking services.

This option was created to provide a timeout capability to system services, thus allowing applications to include better error detection, and recovery capabilities.

_POSIX_TIMERS
The system provides higher resolution clocks with multiple timers per process.

This option was created to support historical systems that did not provide the features. This option is appropriate for applications requiring higher resolution timestamps or needing to control the timing of multiple activities. It should only be required if needed, but it should never be prohibited.

_POSIX_TRACE
The system supports the Trace option.

This option was created to allow applications to perform tracing.

_POSIX_TRACE_EVENT_FILTER
The system supports the Trace Event Filter option.

This option is dependent on support of the Trace option.

_POSIX_TRACE_INHERIT
The system supports the Trace Inherit option.

This option is dependent on support of the Trace option.

_POSIX_TRACE_LOG
The system supports the Trace Log option.

This option is dependent on support of the Trace option.

_POSIX_TYPED_MEMORY_OBJECTS
The system supports the Typed Memory Objects option.

This option was created to allow realtime applications to access different kinds of physical memory, and allow processes in these applications to share portions of this memory.

D.3.5 Configurable Limits

In general, the configurable limits in the <limits.h> header defined in the Base Definitions volume of IEEE Std 1003.1-2001 have been set to minimal values; many applications or implementations may require larger values. No profile can cite lower values.

{AIO_LISTIO_MAX}
The current minimum is likely to be inadequate for most applications. It is expected that this value will be increased by profiles requiring support for list input and output operations.
{AIO_MAX}
The current minimum is likely to be inadequate for most applications. It is expected that this value will be increased by profiles requiring support for asynchronous input and output operations.
{AIO_PRIO_DELTA_MAX}
The functionality associated with this limit is needed only by sophisticated applications. It is not expected that this limit would need to be increased under a general-purpose profile.
{ARG_MAX}
The current minimum is likely to need to be increased for profiles, particularly as larger amounts of information are passed through the environment. Many implementations are believed to support larger values.
{CHILD_MAX}
The current minimum is suitable only for systems where a single user is not running applications in parallel. It is significantly too low for any system also requiring windows, and if _POSIX_JOB_CONTROL is specified, it should be raised.
{CLOCKRES_MIN}
It is expected that profiles will require a finer granularity clock, perhaps as fine as 1 µs, represented by a value of 1000 for this limit.
{DELAYTIMER_MAX}
It is believed that most implementations will provide larger values.
{LINK_MAX}
For most applications and usage, the current minimum is adequate. Many implementations have a much larger value, but this should not be used as a basis for raising the value unless the applications to be used require it.
{LOGIN_NAME_MAX}
This is not actually a limit, but an implementation parameter. No profile should impose a requirement on this value.
{MAX_CANON}
For most purposes, the current minimum is adequate. Unless high-speed burst serial devices are used, it should be left as is.
{MAX_INPUT}
See {MAX_CANON}.
{MQ_OPEN_MAX}
The current minimum should be adequate for most profiles.
{MQ_PRIO_MAX}
The current minimum corresponds to the required number of process scheduling priorities. Many realtime practitioners believe that the number of message priority levels ought to be the same as the number of execution scheduling priorities.
{NAME_MAX}
Many implementations now support larger values, and many applications and users assume that larger names can be used. Many existing profiles also specify a larger value. Specifying this value will reduce the number of conforming implementations, although this might not be a significant consideration over time. Values greater than 255 should not be required.
{NGROUPS_MAX}
The value selected will typically be 8 or larger.
{OPEN_MAX}
The historically common value for this has been 20. Many implementations support larger values. If applications that use larger values are anticipated, an appropriate value should be specified.
{PAGESIZE}
This is not actually a limit, but an implementation parameter. No profile should impose a requirement on this value.
{PATH_MAX}
Historically, the minimum has been either 1024 or indefinite, depending on the implementation. Few applications actually require values larger than 256, but some users may create file hierarchies that must be accessed with longer paths. This value should only be changed if there is a clear requirement.
{PIPE_BUF}
The current minimum is adequate for most applications. Historically, it has been larger. If applications that write single transactions larger than this are anticipated, it should be increased. Applications that write lines of text larger than this probably do not need it increased, as the text line is delimited by a <newline>.
{POSIX_VERSION}
This is actually not a limit, but a standard version stamp. Generally, a profile should specify IEEE Std 1003.1-2001 by a name in the normative references section, not this value.
{PTHREAD_DESTRUCTOR_ITERATIONS}
It is unlikely that applications will need larger values to avoid loss of memory resources.
{PTHREAD_KEYS_MAX}
The current value should be adequate for most profiles.
{PTHREAD_STACK_MIN}
This should not be treated as an actual limit, but as an implementation parameter. No profile should impose a requirement on this value.
{PTHREAD_THREADS_MAX}
It is believed that most implementations will provide larger values.
{RTSIG_MAX}
The current limit was chosen so that the set of POSIX.1 signal numbers can fit within a 32-bit field. It is recognized that most existing implementations define many more signals than are specified in POSIX.1 and, in fact, many implementations have already exceeded 32 signals (including the "null signal"). Support of {_POSIX_RTSIG_MAX} additional signals may push some implementations over the single 32-bit word line, but is unlikely to push any implementations that are already over that line beyond the 64 signal line.
{SEM_NSEMS_MAX}
The current value should be adequate for most profiles.
{SEM_VALUE_MAX}
The current value should be adequate for most profiles.
{SSIZE_MAX}
This limit reflects fundamental hardware characteristics (the size of an integer), and should not be specified unless it is clearly required. Extreme care should be taken to assure that any value that might be specified does not unnecessarily eliminate implementations because of accidents of hardware design.
{STREAM_MAX}
This limit is very closely related to {OPEN_MAX}. It should never be larger than {OPEN_MAX}, but could reasonably be smaller for application areas where most files are not accessed through stdio. Some implementations may limit {STREAM_MAX} to 20 but allow {OPEN_MAX} to be considerably larger. Such implementations should be allowed for if the applications permit.
{TIMER_MAX}
The current limit should be adequate for most profiles, but it may need to be larger for applications with a large number of asynchronous operations.
{TTY_NAME_MAX}
This is not actually a limit, but an implementation parameter. No profile should impose a requirement on this value.
{TZNAME_MAX}
The minimum has been historically adequate, but if longer timezone names are anticipated (particularly such values as UTC-1), this should be increased.

D.3.6 Optional Behavior

In IEEE Std 1003.1-2001, there are no instances of the terms unspecified, undefined, implementation-defined, or with the verbs "may" or "need not", that the developers of IEEE Std 1003.1-2001 anticipate or sanction as suitable for profile or test method citation. All of these are merely warnings to conforming applications to avoid certain areas that can vary from system to system, and even over time on the same system. In many cases, these terms are used explicitly to support extensions, but profiles should not anticipate and require such extensions; future versions of IEEE Std 1003.1 may do so.


UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[ Main Index | XBD | XCU | XSH | XRAT ]


Footnotes

1.
The utilities listed with an asterisk here and later in this section are present only on systems which support the User Portability Utilities option. There may be further restrictions on the utilities offered with various configuration option combinations; see the individual utility descriptions.
2.
There are no formally approved profiles of IEEE Std 1003.1-2001 at the time of publication; the reference here is to various profiles generated by private bodies or governments.