xbd_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

<th align="center">
<p class="tent"><b>Value</b></p>
</th>
<th align="center">
<p class="tent"><b>Value</b></p>
</th>
</tr>

<tr valign="top">
<td align="left">
<p class="tent">Standard</p>
</td>
<td align="center">
<p class="tent"><i>Xs</i></p>
</td>
<td align="center">
<p class="tent"><i>Ys</i></p>
</td>
<td align="center">
<p class="tent"><i>Zs</i></p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent">Profile</p>
</td>
<td align="center">
<p class="tent"><i>Xp</i> == <i>Xs</i></p>
</td>
<td align="center">
<p class="tent"><i>Yp</i> &gt;= <i>Ys</i></p>
</td>
<td align="center">
<p class="tent"><i>Zp</i> &lt;= <i>Zs</i></p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">(No change)</p>
</td>
<td align="center">
<p class="tent">(May increase the limit)</p>
</td>
<td align="center">
<p class="tent">(May decrease the limit)</p>
</td>
</tr>
</table>
</center>

<p>The intent is that ranges specified by limits in profiles be entirely contained within the corresponding ranges of the base
standard or standards being profiled, and that the unlimited end of a range in a base standard must remain unlimited in any profile
of that standard.</p>

<p>Thus, the fixed _POSIX_* limits are constants and must not be changed by a profile. The variable counterparts (typically without
the leading _POSIX_) can be changed but still remain semantically the same; that is, they still allow implementation values to vary
as long as they meet the requirements for that value (be it a minimum or maximum).</p>

<p>Where a profile does not provide a feature upon which a limit is based, the limit is not relevant. Applications written to that
profile should be written to operate independently of the value of the limit.</p>

<p>An example which has previously allowed implementations to support both the base standard and two other profiles in a compatible
manner follows:</p>

<blockquote>
<pre>
<tt>Base standard (POSIX.1-1996): _POSIX_CHILD_MAX 6
Base standard: CHILD_MAX   minimum maximum _POSIX_CHILD_MAX
    FIPS profile/SUSv2  CHILD_MAX   25 (minimum maximum)
</tt>
</pre>
</blockquote>

<p>Another example:</p>

<blockquote>
<pre>
<tt>Base standard (POSIX.1-1996): _POSIX_NGROUPS_MAX 0
Base standard: NGROUPS_MAX   minimum maximum _POSIX_NGROUP_MAX
    FIPS profile/SUSv2  NGROUPS_MAX   8
</tt>
</pre>
</blockquote>

<p>A profile may lower a minimum maximum below the equivalent _POSIX value:</p>

<blockquote>
<pre>
<tt>Base standard: _POSIX_foo_MAX   Z
Base standard: foo_MAX   _POSIX_foo_MAX
    profile standard : foo_MAX   X  (X can be less than, equal to,
                                    or greater than  _POSIX_foo_MAX)
</tt>
</pre>
</blockquote>

<p>In this case an implementation conforming to the profile may not conform to the base standard, but an implementation to the base
standard will conform to the profile.</p>

<h5><a name="tag_01_02_01_07"></a>Options</h5>

<p>The final subsections within <i>Implementation Conformance</i> list the core options within IEEE&nbsp;Std&nbsp;1003.1-2001. This
includes both options for the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001 and the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>

<h4><a name="tag_01_02_02"></a>Application Conformance</h4>

<p>These definitions guide users or adaptors of applications in determining on which implementations an application will run and
how much adaptation would be required to make it run on others. These definitions are modeled after related ones in the ISO&nbsp;C
standard.</p>

<p>POSIX.1 occasionally uses the expressions &quot;portable application&quot; or &quot;conforming application&quot;. As they are used, these are
synonyms for any of these terms. The differences between the classes of application conformance relate to the requirements for
other standards, the options supported (such as the XSI extension) or, in the case of the Conforming POSIX.1 Application Using
Extensions, to implementation extensions. When one of the less explicit expressions is used, it should be apparent from the context
of the discussion which of the more explicit names is appropriate</p>

<h5><a name="tag_01_02_02_01"></a>Strictly Conforming POSIX Application</h5>

<p>This definition is analogous to that of an ISO&nbsp;C standard &quot;conforming program&quot;.</p>

<p>The major difference between a Strictly Conforming POSIX Application and an ISO&nbsp;C standard strictly conforming program is
that the latter is not allowed to use features of POSIX that are not in the ISO&nbsp;C standard.</p>

<h5><a name="tag_01_02_02_02"></a>Conforming POSIX Application</h5>

<p>Examples of &lt;National Bodies&gt; include ANSI, BSI, and AFNOR.</p>

<h5><a name="tag_01_02_02_03"></a>Conforming POSIX Application Using Extensions</h5>

<p>Due to possible requirements for configuration or implementation characteristics in excess of the specifications in <a href=
"../basedefs/limits.h.html"><i>&lt;limits.h&gt;</i></a> or related to the hardware (such as array size or file space), not every
Conforming POSIX Application Using Extensions will run on every conforming implementation.</p>

<h5><a name="tag_01_02_02_04"></a>Strictly Conforming XSI Application</h5>

<p>This is intended to be upwards-compatible with the definition of a Strictly Conforming POSIX Application, with the addition of
the facilities and functionality included in the XSI extension.</p>

<h5><a name="tag_01_02_02_05"></a>Conforming XSI Application Using Extensions</h5>

<p>Such applications may use extensions beyond the facilities defined by IEEE&nbsp;Std&nbsp;1003.1-2001 including the XSI
extension, but need to document the additional requirements.</p>

<h4><a name="tag_01_02_03"></a>Language-Dependent Services for the C Programming Language</h4>

<p>POSIX.1 is, for historical reasons, both a specification of an operating system interface, shell and utilities, and a C binding
for that specification. Efforts had been previously undertaken to generate a language-independent specification; however, that had
failed, and the fact that the ISO&nbsp;C standard is the <i>de facto</i> primary language on POSIX and the UNIX system makes this a
necessary and workable situation.</p>

<h4><a name="tag_01_02_04"></a>Other Language-Related Specifications</h4>

<p>There is no additional rationale provided for this section.</p>


<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; 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>