433 lines
20 KiB
HTML
433 lines
20 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>Rationale for Base Definitions</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
|
|
<basefont size="3"> <!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h2><a name="tag_01"></a>Rationale for Base Definitions</h2>
|
|
|
|
<h3><a name="tag_01_01"></a>Introduction</h3>
|
|
|
|
<h4><a name="tag_01_01_01"></a>Scope</h4>
|
|
|
|
<p>IEEE Std 1003.1-2001 is one of a family of standards known as POSIX. The family of standards extends to many topics;
|
|
IEEE Std 1003.1-2001 is known as POSIX.1 and consists of both operating system interfaces and shell and utilities.
|
|
IEEE Std 1003.1-2001 is technically identical to The Open Group Base Specifications, Issue 6, which comprise the core
|
|
volumes of the Single UNIX Specification, Version 3.</p>
|
|
|
|
<h5><a name="tag_01_01_01_01"></a>Scope of IEEE Std 1003.1-2001</h5>
|
|
|
|
<p>The (paraphrased) goals of this development were to produce a single common revision to the overlapping POSIX.1 and POSIX.2
|
|
standards, and the Single UNIX Specification, Version 2. As such, the scope of the revision includes the scopes of the original
|
|
documents merged.</p>
|
|
|
|
<p>Since the revision includes merging the Base volumes of the Single UNIX Specification, many features that were previously not
|
|
"adopted" into earlier revisions of POSIX.1 and POSIX.2 are now included in IEEE Std 1003.1-2001. In most cases, these
|
|
additions are part of the XSI extension; in other cases the standard developers decided that now was the time to migrate these to
|
|
the base standard.</p>
|
|
|
|
<p>The Single UNIX Specification programming environment provides a broad-based functional set of interfaces to support the porting
|
|
of existing UNIX applications and the development of new applications. The environment also supports a rich set of tools for
|
|
application development.</p>
|
|
|
|
<p>The majority of the obsolescent material from the existing POSIX.1 and POSIX.2 standards, and material marked LEGACY from The
|
|
Open Group's Base specifications, has been removed in this revision. New members of the Legacy Option Group have been added,
|
|
reflecting the advance in understanding of what is required.</p>
|
|
|
|
<p>The following IEEE standards have been added to the base documents in this revision:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>IEEE Std 1003.1d-1999</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>IEEE Std 1003.1j-2000</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>IEEE Std 1003.1q-2000</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>IEEE P1003.1a draft standard</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>IEEE Std 1003.2d-1994</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>IEEE P1003.2b draft standard</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Selected parts of IEEE Std 1003.1g-2000</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Only selected parts of IEEE Std 1003.1g-2000 were included. This was because there is much duplication between the
|
|
XNS, Issue 5.2 specification (another base document) and the material from IEEE Std 1003.1g-2000, the former document
|
|
being aligned with the latest networking specifications for IPv6. Only the following sections of IEEE Std 1003.1g-2000
|
|
were considered for inclusion:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>General terms related to sockets (Section 2.2.2)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Socket concepts (Sections 5.1 through 5.3 inclusive)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The <a href="../functions/pselect.html"><i>pselect</i>()</a> function (Sections 6.2.2.1 and 6.2.3)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The <a href="../basedefs/sys/select.h.html"><i><sys/select.h></i></a> header (Section 6.2)</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The following were requirements on IEEE Std 1003.1-2001:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>Backward-compatibility</p>
|
|
|
|
<p>It was agreed that there should be no breakage of functionality in the existing base documents. This requirement was tempered by
|
|
changes introduced due to interpretations and corrigenda on the base documents, and any changes introduced in the
|
|
ISO/IEC 9899:1999 standard (C Language).</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Architecture and n-bit neutral</p>
|
|
|
|
<p>The common standard should not make any implicit assumptions about the system architecture or size of data types; for example,
|
|
previously some 32-bit implicit assumptions had crept into the standards.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Extensibility</p>
|
|
|
|
<p>It should be possible to extend the common standard without breaking backwards-compatibility. For example, the name space should
|
|
be reserved and structured to avoid duplication of names between the standard and extensions to it.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h5><a name="tag_01_01_01_02"></a>POSIX.1 and the ISO C Standard</h5>
|
|
|
|
<p>Previous revisions of POSIX.1 built upon the ISO C standard by reference only. This revision takes a different
|
|
approach.</p>
|
|
|
|
<p>The standard developers believed it essential for a programmer to have a single complete reference place, but recognized that
|
|
deference to the formal standard had to be addressed for the duplicate interface definitions between the ISO C standard and
|
|
the Single UNIX Specification.</p>
|
|
|
|
<p>It was agreed that where an interface has a version in the ISO C standard, the DESCRIPTION section should describe the
|
|
relationship to the ISO C standard and markings should be added as appropriate to show where the ISO C standard has been
|
|
extended in the text.</p>
|
|
|
|
<p>A block of text was added to the start of each affected reference page stating whether the page is aligned with the ISO C
|
|
standard or extended. Each page was parsed for additions beyond the ISO C standard (that is, including both POSIX and UNIX
|
|
extensions), and these extensions are marked as CX extensions (for C Extensions).</p>
|
|
|
|
<h5><a name="tag_01_01_01_03"></a>FIPS Requirements</h5>
|
|
|
|
<p>The Federal Information Processing Standards (FIPS) are a series of U.S. government procurement standards managed and maintained
|
|
on behalf of the U.S. Department of Commerce by the National Institute of Standards and Technology (NIST).</p>
|
|
|
|
<p>The following restrictions have been made in this version of IEEE Std 1003.1 in order to align with FIPS 151-2
|
|
requirements:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The implementation supports _POSIX_CHOWN_RESTRICTED.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The limit {NGROUPS_MAX} is now greater than or equal to 8.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports the setting of the group ID of a file (when it is created) to that of the parent directory.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports _POSIX_SAVED_IDS.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports _POSIX_VDISABLE.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports _POSIX_JOB_CONTROL.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports _POSIX_NO_TRUNC.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The <a href="../functions/read.html"><i>read</i>()</a> function returns the number of bytes read when interrupted by a signal
|
|
and does not return -1.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The <a href="../functions/write.html"><i>write</i>()</a> function returns the number of bytes written when interrupted by a
|
|
signal and does not return -1.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>In the environment for the login shell, the environment variables <i>LOGNAME</i> and <i>HOME</i> are defined and have the
|
|
properties described in IEEE Std 1003.1-2001.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The value of {CHILD_MAX} is now greater than or equal to 25.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The value of {OPEN_MAX} is now greater than or equal to 20.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The implementation supports the functionality associated with the symbols CS7, CS8, CSTOPB, PARODD, and PARENB defined in <a
|
|
href="../basedefs/termios.h.html"><i><termios.h></i></a>.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h4><a name="tag_01_01_02"></a>Conformance</h4>
|
|
|
|
<p>See <a href="xbd_chap02.html#tag_01_02"><i>Conformance</i></a> .</p>
|
|
|
|
<h4><a name="tag_01_01_03"></a>Normative References</h4>
|
|
|
|
<p>There is no additional rationale provided for this section.</p>
|
|
|
|
<h4><a name="tag_01_01_04"></a>Terminology</h4>
|
|
|
|
<p>The meanings specified in IEEE Std 1003.1-2001 for the words <i>shall</i>, <i>should</i>, and <i>may</i> are mandated
|
|
by ISO/IEC directives.</p>
|
|
|
|
<p>In the Rationale (Informative) volume of IEEE Std 1003.1-2001, the words <i>shall</i>, <i>should</i>, and <i>may</i>
|
|
are sometimes used to illustrate similar usages in IEEE Std 1003.1-2001. However, the rationale itself does not specify
|
|
anything regarding implementations or applications.</p>
|
|
|
|
<h4><a name="tag_01_01_05"></a>conformance document</h4>
|
|
|
|
<p>As a practical matter, the conformance document is effectively part of the system documentation. Conformance documents are
|
|
distinguished by IEEE Std 1003.1-2001 so that they can be referred to distinctly.</p>
|
|
|
|
<h4><a name="tag_01_01_06"></a>implementation-defined</h4>
|
|
|
|
<p>This definition is analogous to that of the ISO C standard and, together with "undefined" and "unspecified", provides a
|
|
range of specification of freedom allowed to the interface implementor.</p>
|
|
|
|
<h4><a name="tag_01_01_07"></a>may</h4>
|
|
|
|
<p>The use of <i>may</i> has been limited as much as possible, due both to confusion stemming from its ordinary English meaning and
|
|
to objections regarding the desirability of having as few options as possible and those as clearly specified as possible.</p>
|
|
|
|
<p>The usage of <i>can</i> and <i>may</i> were selected to contrast optional application behavior (can) against optional
|
|
implementation behavior (may).</p>
|
|
|
|
<h4><a name="tag_01_01_08"></a>shall</h4>
|
|
|
|
<p>Declarative sentences are sometimes used in IEEE Std 1003.1-2001 as if they included the word <i>shall</i>, and
|
|
facilities thus specified are no less required. For example, the two statements:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>The <i>foo</i>() function shall return zero.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The <i>foo</i>() function returns zero.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>are meant to be exactly equivalent.</p>
|
|
|
|
<h4><a name="tag_01_01_09"></a>should</h4>
|
|
|
|
<p>In IEEE Std 1003.1-2001, the word <i>should</i> does not usually apply to the implementation, but rather to the
|
|
application. Thus, the important words regarding implementations are <i>shall</i>, which indicates requirements, and <i>may</i>,
|
|
which indicates options.</p>
|
|
|
|
<h4><a name="tag_01_01_10"></a>obsolescent</h4>
|
|
|
|
<p>The term "obsolescent" means "do not use this feature in new applications". The obsolescence concept is not an ideal
|
|
solution, but was used as a method of increasing consensus: many more objections would be heard from the user community if some of
|
|
these historical features were suddenly withdrawn without the grace period obsolescence implies. The phrase "may be considered for
|
|
withdrawal in future revisions" implies that the result of that consideration might in fact keep those features indefinitely if
|
|
the predominance of applications do not migrate away from them quickly.</p>
|
|
|
|
<h4><a name="tag_01_01_11"></a>legacy</h4>
|
|
|
|
<p>The term "legacy" was added for compatibility with the Single UNIX Specification. It means "this feature is historic and
|
|
optional; do not use this feature in new applications. There are alternative interfaces that are more suitable.". It is used
|
|
exclusively for XSI extensions, and includes facilities that were mandatory in previous versions of the base document but are
|
|
optional in this revision. This is a way to "sunset" the usage of certain functions. Application writers should not rely on the
|
|
existence of these facilities in new applications, but should follow the migration path detailed in the APPLICATION USAGE sections
|
|
of the relevant pages.</p>
|
|
|
|
<p>The terms "legacy" and "obsolescent" are different: a feature marked LEGACY is not recommended for new work and need not be
|
|
present on an implementation (if the XSI Legacy Option Group is not supported). A feature noted as obsolescent is supported by all
|
|
implementations, but may be removed in a future revision; new applications should not use these features.</p>
|
|
|
|
<h4><a name="tag_01_01_12"></a>system documentation</h4>
|
|
|
|
<p>The system documentation should normally describe the whole of the implementation, including any extensions provided by the
|
|
implementation. Such documents normally contain information at least as detailed as the specifications in
|
|
IEEE Std 1003.1-2001. Few requirements are made on the system documentation, but the term is needed to avoid a dangling
|
|
pointer where the conformance document is permitted to point to the system documentation.</p>
|
|
|
|
<h4><a name="tag_01_01_13"></a>undefined</h4>
|
|
|
|
<p>See <i>implementation-defined</i>.</p>
|
|
|
|
<h4><a name="tag_01_01_14"></a>unspecified</h4>
|
|
|
|
<p>See <i>implementation-defined</i>.</p>
|
|
|
|
<p>The definitions for "unspecified" and "undefined" appear nearly identical at first examination, but are not. The term
|
|
"unspecified" means that a conforming application may deal with the unspecified behavior, and it should not care what the outcome
|
|
is. The term "undefined" says that a conforming application should not do it because no definition is provided for what it does
|
|
(and implicitly it would care what the outcome was if it tried it). It is important to remember, however, that if the syntax
|
|
permits the statement at all, it must have some outcome in a real implementation.</p>
|
|
|
|
<p>Thus, the terms "undefined" and "unspecified" apply to the way the application should think about the feature. In terms of
|
|
the implementation, it is always "defined''-there is always some result, even if it is an error. The implementation is free to
|
|
choose the behavior it prefers.</p>
|
|
|
|
<p>This also implies that an implementation, or another standard, could specify or define the result in a useful fashion. The terms
|
|
apply to IEEE Std 1003.1-2001 specifically.</p>
|
|
|
|
<p>The term "implementation-defined" implies requirements for documentation that are not required for "undefined" (or
|
|
"unspecified"). Where there is no need for a conforming program to know the definition, the term "undefined" is used, even
|
|
though "implementation-defined" could also have been used in this context. There could be a fourth term, specifying "this
|
|
standard does not say what this does; it is acceptable to define it in an implementation, but it does not need to be documented",
|
|
and undefined would then be used very rarely for the few things for which any definition is not useful. In particular,
|
|
implementation-defined is used where it is believed that certain classes of application will need to know such details to determine
|
|
whether the application can be successfully ported to the implementation. Such applications are not always strictly portable, but
|
|
nevertheless are common and useful; often the requirements met by the application cannot be met without dealing with the issues
|
|
implied by "implementation-defined".</p>
|
|
|
|
<p>In many places IEEE Std 1003.1-2001 is silent about the behavior of some possible construct. For example, a variable
|
|
may be defined for a specified range of values and behaviors are described for those values; nothing is said about what happens if
|
|
the variable has any other value. That kind of silence can imply an error in the standard, but it may also imply that the standard
|
|
was intentionally silent and that any behavior is permitted. There is a natural tendency to infer that if the standard is silent, a
|
|
behavior is prohibited. That is not the intent. Silence is intended to be equivalent to the term "unspecified".</p>
|
|
|
|
<p>The term "application" is not defined in IEEE Std 1003.1-2001; it is assumed to be a part of general computer
|
|
science terminology.</p>
|
|
|
|
<p>Three terms used within IEEE Std 1003.1-2001 overlap in meaning: "macro", "symbolic name", and "symbolic
|
|
constant".</p>
|
|
|
|
<h4><a name="tag_01_01_15"></a>macro</h4>
|
|
|
|
<p>This usually describes a C preprocessor symbol, the result of the <b>#define</b> operator, with or without an argument. It may
|
|
also be used to describe similar mechanisms in editors and text processors.</p>
|
|
|
|
<h4><a name="tag_01_01_16"></a>symbolic name</h4>
|
|
|
|
<p>This can also refer to a C preprocessor symbol (without arguments), but is also used to refer to the names for characters in
|
|
character sets. In addition, it is sometimes used to refer to host names and even filenames.</p>
|
|
|
|
<h4><a name="tag_01_01_17"></a>symbolic constant</h4>
|
|
|
|
<p>This also refers to a C preprocessor symbol (also without arguments).</p>
|
|
|
|
<p>In most cases, the difference in semantic content is negligible to nonexistent. Readers should not attempt to read any meaning
|
|
into the various usages of these terms.</p>
|
|
|
|
<h4><a name="tag_01_01_18"></a>Portability</h4>
|
|
|
|
<p>To aid the identification of options within IEEE Std 1003.1-2001, a notation consisting of margin codes and shading is
|
|
used. This is based on the notation used in previous revisions of The Open Group's Base specifications.</p>
|
|
|
|
<p>The benefit of this approach is a reduction in the number of <i>if</i> statements within the running text, that makes the text
|
|
easier to read, and also an identification to the programmer that they need to ensure that their target platforms support the
|
|
underlying options. For example, if functionality is marked with THR in the margin, it will be available on all systems supporting
|
|
the Threads option, but may not be available on some others.</p>
|
|
|
|
<h5><a name="tag_01_01_18_01"></a>Codes</h5>
|
|
|
|
<p>This section includes codes for options defined in the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/xbd_chap02.html#tag_02_01_06">Section 2.1.6, Options</a>, and the following additional codes for other purposes:</p>
|
|
|
|
<dl compact>
|
|
<dt>CX</dt>
|
|
|
|
<dd>This margin code is used to denote extensions beyond the ISO C standard. For interfaces that are duplicated between
|
|
IEEE Std 1003.1-2001 and the ISO C standard, a CX introduction block describes the nature of the duplication, with
|
|
any extensions appropriately CX marked and shaded.
|
|
|
|
<p>Where an interface is added to an ISO C standard header, within the header the interface has an appropriate margin marker
|
|
and shading (for example, CX, XSI, TSF, and so on) and the same marking appears on the reference page in the SYNOPSIS section. This
|
|
enables a programmer to easily identify that the interface is extending an ISO C standard header.</p>
|
|
</dd>
|
|
|
|
<dt>MX</dt>
|
|
|
|
<dd>This margin code is used to denote IEC 60559:1989 standard floating-point extensions.</dd>
|
|
|
|
<dt>OB</dt>
|
|
|
|
<dd>This margin code is used to denote obsolescent behavior and thus flag a possible future applications portability warning.</dd>
|
|
|
|
<dt>OH</dt>
|
|
|
|
<dd>The Single UNIX Specification has historically tried to reduce the number of headers an application has had to include when
|
|
using a particular interface. Sometimes this was fewer than the base standard, and hence a notation is used to flag which headers
|
|
are optional if you are using a system supporting the XSI extension.</dd>
|
|
|
|
<dt>XSI</dt>
|
|
|
|
<dd>This code is used to denote interfaces and facilities within interfaces only required on systems supporting the XSI extension.
|
|
This is introduced to support the Single UNIX Specification.</dd>
|
|
|
|
<dt>XSR</dt>
|
|
|
|
<dd>This code is used to denote interfaces and facilities within interfaces only required on systems supporting STREAMS. This is
|
|
introduced to support the Single UNIX Specification, although it is defined in a way so that it can stand alone from the XSI
|
|
notation.</dd>
|
|
</dl>
|
|
|
|
<h5><a name="tag_01_01_18_02"></a>Margin Code Notation</h5>
|
|
|
|
<p>Since some features may depend on one or more options, or require more than one option, a notation is used. Where a feature
|
|
requires support of a single option, a single margin code will occur in the margin. If it depends on two options and both are
|
|
required, then the codes will appear with a <space> separator. If either of two options are required, then a logical OR is
|
|
denoted using the <tt>'|'</tt> symbol. If more than two codes are used, a special notation is used.</p>
|
|
|
|
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|