This section contains information to satisfy various international requirements:
User Requirements describes perceived user requirements.
Portability Capabilities indicates how the facilities of IEEE Std 1003.1-2001 satisfy those requirements.
Profiling Considerations 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.
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:
Those employing applications written in high-level languages, such as C, Ada, or FORTRAN.
Users who desire conforming applications that do not necessarily require the characteristics of high-level languages (for example, the speed of execution of compiled languages or the relative security of source code intellectual property inherent in the compilation process).
Users who desire conforming applications that can be developed quickly and can be modified readily without the use of compilers and other system components that may be unavailable on small systems or those without special application development capabilities.
Users who interact with a system to achieve general-purpose time-sharing capabilities common to most business or government offices or academic environments: editing, filing, inter-user communications, printing, and so on.
Users who develop applications for POSIX-conformant systems.
Users who develop applications for UNIX systems.
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.
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.
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.
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.
Applications must be able to access the external environment to communicate their input and results.
Applications must have sufficient control of resource allocation to ensure the timeliness of interactions with external objects.
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.
The interaction between the C language I/O subsystem ( stdio) and the I/O subsystem of IEEE Std 1003.1-2001 must be specified.
The effects of the environment of IEEE Std 1003.1-2001 on the internationalization facilities of the C language must be specified.
Certain functions in the C language must be extended to support the additional capabilities provided by IEEE Std 1003.1-2001.
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.
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.
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.
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.
Create, delete, move/rename, copy, backup/archive, and display files and directories. These facilities should be available to both conforming applications and interactive users.
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.
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.
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.
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.
Develop (create and manage source files, compile/interpret, debug) portable open systems applications and package them for distribution to, and updating of, other systems.
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:
Configuration Interrogation
Process Management
Access to Data
Access to the Environment
Access to Determinism and Performance Enhancements
Operating System-Dependent Profile
I/O Interaction
Internationalization Interaction
C-Language Extensions
Command Language
Interactive Facilities
Accomplish Multiple Tasks Simultaneously
Complex Data Manipulation
File Hierarchy Manipulation
Locale Configuration
Inter-User Communication
System Environment
Printing
Software Development
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).
None directly. However, as new areas are added, there will be a need for additional capability in this area.
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.
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.
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.
Detailed control of common device classes, specifically magnetic tape, is not provided.
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.
IEEE Std 1003.1-2001 makes no distinction between text and binary files. The values of EXIT_SUCCESS and EXIT_FAILURE are further defined.
None known, but the ISO C standard may contain some additional options that could be specified.
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.
None.
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.
None.
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.
None.
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.
None.
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.
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.
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.
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.
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.
Sophisticated text formatting utilities, such as troff or TeX, are not included. Standards work in the area of SGML may satisfy this.
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.
Some graphical user interfaces offer more intuitive file manager components that allow file manipulation through the use of icons for novice users.
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.
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.
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.
None.
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.
None.
The following utilities address user requirements in this area: pr and lp.
There are no features to control the formatting or scheduling of the print jobs.
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.
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.
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.
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) .
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.
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 .
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.
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.
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.
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.
As with C, this option is needed on any system developing or installing FORTRAN applications in source form.
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.
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.
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.
Very few of the limits need to be increased for profiles. No profile can cite lower values.
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.
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.
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.
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.
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.
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.
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.
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.
This option was created to allow systems to transition to IPv6.
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.
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.
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.
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:
An asynchronous event handler function that must respond to external events in a deterministic manner such that page faults cannot be tolerated
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.
XSI-conformant systems support this option.
The provision of this option typically imposes additional hardware requirements. It should never be prohibited.
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.
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.
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.
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.
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.
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.
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.
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.
This option provides applications with an efficient mechanism to spawn execution of a new process.
This option was created to support a simple and efficient synchronization mechanism for threads executing in multi-processor systems.
This option provides applications with a new scheduling policy for scheduling aperiodic processes or threads in hard realtime applications.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Support for this option provides applications with a new scheduling policy for scheduling aperiodic threads in hard realtime applications.
This option was created to provide a timeout capability to system services, thus allowing applications to include better error detection, and recovery capabilities.
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.
This option was created to allow applications to perform tracing.
This option is dependent on support of the Trace option.
This option is dependent on support of the Trace option.
This option is dependent on support of the Trace 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.
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.
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.