lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory Ref-docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:21:47 -05:00
parent 5a46ddb732
commit ef50495c9d
2492 changed files with 1609142 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1326
Ref-docs/POSIX/susv3/xrat/contents.html Normal file
View File

File diff suppressed because it is too large Load Diff

1568
Ref-docs/POSIX/susv3/xrat/port.html Normal file
View File

File diff suppressed because it is too large Load Diff

119
Ref-docs/POSIX/susv3/xrat/style.css Normal file
View File

@@ -0,0 +1,119 @@
A:link { COLOR: #0000FF; }
A:visited { COLOR: #6666FF; }
A:active { COLOR: #6666FF; }
A:hover {
COLOR: #FF0000;
TEXT-DECORATION: underline;
}
H1{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006600;
BACKGROUND-COLOR: white;
FONT-SIZE: 20pt;
}
H2{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006600;
BACKGROUND-COLOR: white;
FONT-SIZE: 15pt;
}
H3{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006600;
BACKGROUND-COLOR: white;
FONT-SIZE: 14pt;
}
H4{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006600;
BACKGROUND-COLOR: white;
FONT-Style: italic;
FONT-SIZE: 12pt;
}
H5{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006600;
BACKGROUND-COLOR: white;
FONT-SIZE: 11pt;
}
H6{
FONT-FAMILY: Arial, Helvetica, sans-serif;
COLOR: #006666;
BACKGROUND-COLOR: white;
FONT-SIZE: 10pt;
font-weight : bold;
}
BODY
{
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
FONT-SIZE: 10pt;
MARGIN-LEFT: 3pt;
MARGIN-TOP: 2pt;
COLOR: #000000;
BACKGROUND-COLOR: white;
}
BLOCKQUOTE.synopsis
{
FONT-SIZE: 11pt;
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
}
/*em { font-style: italic; font-weight: normal; font-size:10pt; }*/
BLOCKQUOTE.body
{
FONT-SIZE: 10pt;
MARGIN-BOTTOM: 0pt;
MARGIN-LEFT: 0pt;
MARGIN-TOP: 0pt;
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
TEXT-INDENT: 10px;
}
TABLE {
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
FONT-SIZE: 10pt;
MARGIN-LEFT: 0pt;
MARGIN-TOP: 0pt;
COLOR: #000000;
BACKGROUND-COLOR: white;
}
P.tent {
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
FONT-SIZE: 10pt;
}
UL
{
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
FONT-SIZE: 10pt;
COLOR: #000000;
}
LI
{
FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif;
FONT-SIZE: 10pt;
COLOR: #000000;
/* TEXT-INDENT: -10px; */
}
HR
{
COLOR: #009900;
}
div.box { border: none; border-width: thin;
background: rgb(204,204,255);
font-size: 11pt;
}
pre {FONT-SIZE: 11pt; }
pre { font-family: monospace; }

720
Ref-docs/POSIX/susv3/xrat/subprofiles.html Normal file
View File

@@ -0,0 +1,720 @@
<!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>Subprofiling Considerations (Informative)</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 &copy; 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
<!--header end-->
<hr size="2" noshade>
<h2><a name="tag_05"></a>Subprofiling Considerations (Informative)</h2>
<p>This section contains further information to satisfy the requirement that the project scope enable subprofiling of
IEEE&nbsp;Std&nbsp;1003.1-2001. The original intent was to have included a set of options similar to the &quot;Units of Functionality''
contained in IEEE&nbsp;Std&nbsp;1003.13-1998. However, as the development of IEEE&nbsp;Std&nbsp;1003.1-2001 continued, the standard
developers felt it premature to fix these in normative text. The approach instead has been to include a general requirement in
normative text regarding subprofiling and to include an informative section (here) containing a proposed set of subprofiling
options.</p>
<h3><a name="tag_05_01"></a>Subprofiling Option Groups</h3>
<p>The following Option Groups<a href="#tag_foot_1"><sup><small>1</small></sup></a> are defined to support profiling. Systems
claiming support to IEEE&nbsp;Std&nbsp;1003.1-2001 need not implement these options apart from the requirements stated in the Base
Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap02.html#tag_02_01_03">Section 2.1.3, POSIX
Conformance</a>. These Option Groups allow profiles to subset the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001 by
collecting sets of related functions.</p>
<dl compact>
<dt>POSIX_C_LANG_JUMP: Jump Functions</dt>
<dd>
<a href="../functions/longjmp.html"><i>longjmp</i>()</a>, <a href="../functions/setjmp.html"><i>setjmp</i>()</a></dd>
<dt>POSIX_C_LANG_MATH: Maths Library</dt>
<dd>
<a href="../functions/acos.html"><i>acos</i>()</a>, <a href="../functions/acosf.html"><i>acosf</i>()</a>, <a href=
"../functions/acosh.html"><i>acosh</i>()</a>, <a href="../functions/acoshf.html"><i>acoshf</i>()</a>, <a href=
"../functions/acoshl.html"><i>acoshl</i>()</a>, <a href="../functions/acosl.html"><i>acosl</i>()</a>, <a href=
"../functions/asin.html"><i>asin</i>()</a>, <a href="../functions/asinf.html"><i>asinf</i>()</a>, <a href=
"../functions/asinh.html"><i>asinh</i>()</a>, <a href="../functions/asinhf.html"><i>asinhf</i>()</a>, <a href=
"../functions/asinhl.html"><i>asinhl</i>()</a>, <a href="../functions/asinl.html"><i>asinl</i>()</a>, <a href=
"../functions/atan.html"><i>atan</i>()</a>, <a href="../functions/atan2.html"><i>atan2</i>()</a>, <a href=
"../functions/atan2f.html"><i>atan2f</i>()</a>, <a href="../functions/atan2l.html"><i>atan2l</i>()</a>, <a href=
"../functions/atanf.html"><i>atanf</i>()</a>, <a href="../functions/atanh.html"><i>atanh</i>()</a>, <a href=
"../functions/atanhf.html"><i>atanhf</i>()</a>, <a href="../functions/atanhl.html"><i>atanhl</i>()</a>, <a href=
"../functions/atanl.html"><i>atanl</i>()</a>, <a href="../functions/cabs.html"><i>cabs</i>()</a>, <a href=
"../functions/cabsf.html"><i>cabsf</i>()</a>, <a href="../functions/cabsl.html"><i>cabsl</i>()</a>, <a href=
"../functions/cacos.html"><i>cacos</i>()</a>, <a href="../functions/cacosf.html"><i>cacosf</i>()</a>, <a href=
"../functions/cacosh.html"><i>cacosh</i>()</a>, <a href="../functions/cacoshf.html"><i>cacoshf</i>()</a>, <a href=
"../functions/cacoshl.html"><i>cacoshl</i>()</a>, <a href="../functions/cacosl.html"><i>cacosl</i>()</a>, <a href=
"../functions/carg.html"><i>carg</i>()</a>, <a href="../functions/cargf.html"><i>cargf</i>()</a>, <a href=
"../functions/cargl.html"><i>cargl</i>()</a>, <a href="../functions/casin.html"><i>casin</i>()</a>, <a href=
"../functions/casinf.html"><i>casinf</i>()</a>, <a href="../functions/casinh.html"><i>casinh</i>()</a>, <a href=
"../functions/casinhf.html"><i>casinhf</i>()</a>, <a href="../functions/casinhl.html"><i>casinhl</i>()</a>, <a href=
"../functions/casinl.html"><i>casinl</i>()</a>, <a href="../functions/catan.html"><i>catan</i>()</a>, <a href=
"../functions/catanf.html"><i>catanf</i>()</a>, <a href="../functions/catanh.html"><i>catanh</i>()</a>, <a href=
"../functions/catanhf.html"><i>catanhf</i>()</a>, <a href="../functions/catanhl.html"><i>catanhl</i>()</a>, <a href=
"../functions/catanl.html"><i>catanl</i>()</a>, <a href="../functions/cbrt.html"><i>cbrt</i>()</a>, <a href=
"../functions/cbrtf.html"><i>cbrtf</i>()</a>, <a href="../functions/cbrtl.html"><i>cbrtl</i>()</a>, <a href=
"../functions/ccos.html"><i>ccos</i>()</a>, <a href="../functions/ccosf.html"><i>ccosf</i>()</a>, <a href=
"../functions/ccosh.html"><i>ccosh</i>()</a>, <a href="../functions/ccoshf.html"><i>ccoshf</i>()</a>, <a href=
"../functions/ccoshl.html"><i>ccoshl</i>()</a>, <a href="../functions/ccosl.html"><i>ccosl</i>()</a>, <a href=
"../functions/ceil.html"><i>ceil</i>()</a>, <a href="../functions/ceilf.html"><i>ceilf</i>()</a>, <a href=
"../functions/ceill.html"><i>ceill</i>()</a>, <a href="../functions/cexp.html"><i>cexp</i>()</a>, <a href=
"../functions/cexpf.html"><i>cexpf</i>()</a>, <a href="../functions/cexpl.html"><i>cexpl</i>()</a>, <a href=
"../functions/cimag.html"><i>cimag</i>()</a>, <a href="../functions/cimagf.html"><i>cimagf</i>()</a>, <a href=
"../functions/cimagl.html"><i>cimagl</i>()</a>, <a href="../functions/clog.html"><i>clog</i>()</a>, <a href=
"../functions/clogf.html"><i>clogf</i>()</a>, <a href="../functions/clogl.html"><i>clogl</i>()</a>, <a href=
"../functions/conj.html"><i>conj</i>()</a>, <a href="../functions/conjf.html"><i>conjf</i>()</a>, <a href=
"../functions/conjl.html"><i>conjl</i>()</a>, <a href="../functions/copysign.html"><i>copysign</i>()</a>, <a href=
"../functions/copysignf.html"><i>copysignf</i>()</a>, <a href="../functions/copysignl.html"><i>copysignl</i>()</a>, <a href=
"../functions/cos.html"><i>cos</i>()</a>, <a href="../functions/cosf.html"><i>cosf</i>()</a>, <a href=
"../functions/cosh.html"><i>cosh</i>()</a>, <a href="../functions/coshf.html"><i>coshf</i>()</a>, <a href=
"../functions/coshl.html"><i>coshl</i>()</a>, <a href="../functions/cosl.html"><i>cosl</i>()</a>, <a href=
"../functions/cpow.html"><i>cpow</i>()</a>, <a href="../functions/cpowf.html"><i>cpowf</i>()</a>, <a href=
"../functions/cpowl.html"><i>cpowl</i>()</a>, <a href="../functions/cproj.html"><i>cproj</i>()</a>, <a href=
"../functions/cprojf.html"><i>cprojf</i>()</a>, <a href="../functions/cprojl.html"><i>cprojl</i>()</a>, <a href=
"../functions/creal.html"><i>creal</i>()</a>, <a href="../functions/crealf.html"><i>crealf</i>()</a>, <a href=
"../functions/creall.html"><i>creall</i>()</a>, <a href="../functions/csin.html"><i>csin</i>()</a>, <a href=
"../functions/csinf.html"><i>csinf</i>()</a>, <a href="../functions/csinh.html"><i>csinh</i>()</a>, <a href=
"../functions/csinhf.html"><i>csinhf</i>()</a>, <a href="../functions/csinhl.html"><i>csinhl</i>()</a>, <a href=
"../functions/csinl.html"><i>csinl</i>()</a>, <a href="../functions/csqrt.html"><i>csqrt</i>()</a>, <a href=
"../functions/csqrtf.html"><i>csqrtf</i>()</a>, <a href="../functions/csqrtl.html"><i>csqrtl</i>()</a>, <a href=
"../functions/ctan.html"><i>ctan</i>()</a>, <a href="../functions/ctanf.html"><i>ctanf</i>()</a>, <a href=
"../functions/ctanh.html"><i>ctanh</i>()</a>, <a href="../functions/ctanhf.html"><i>ctanhf</i>()</a>, <a href=
"../functions/ctanhl.html"><i>ctanhl</i>()</a>, <a href="../functions/ctanl.html"><i>ctanl</i>()</a>, <a href=
"../functions/erf.html"><i>erf</i>()</a>, <a href="../functions/erfc.html"><i>erfc</i>()</a>, <a href=
"../functions/erfcf.html"><i>erfcf</i>()</a>, <a href="../functions/erfcl.html"><i>erfcl</i>()</a>, <a href=
"../functions/erff.html"><i>erff</i>()</a>, <a href="../functions/erfl.html"><i>erfl</i>()</a>, <a href=
"../functions/exp.html"><i>exp</i>()</a>, <a href="../functions/exp2.html"><i>exp2</i>()</a>, <a href=
"../functions/exp2f.html"><i>exp2f</i>()</a>, <a href="../functions/exp2l.html"><i>exp2l</i>()</a>, <a href=
"../functions/expf.html"><i>expf</i>()</a>, <a href="../functions/expl.html"><i>expl</i>()</a>, <a href=
"../functions/expm1.html"><i>expm1</i>()</a>, <a href="../functions/expm1f.html"><i>expm1f</i>()</a>, <a href=
"../functions/expm1l.html"><i>expm1l</i>()</a>, <a href="../functions/fabs.html"><i>fabs</i>()</a>, <a href=
"../functions/fabsf.html"><i>fabsf</i>()</a>, <a href="../functions/fabsl.html"><i>fabsl</i>()</a>, <a href=
"../functions/fdim.html"><i>fdim</i>()</a>, <a href="../functions/fdimf.html"><i>fdimf</i>()</a>, <a href=
"../functions/fdiml.html"><i>fdiml</i>()</a>, <a href="../functions/floor.html"><i>floor</i>()</a>, <a href=
"../functions/floorf.html"><i>floorf</i>()</a>, <a href="../functions/floorl.html"><i>floorl</i>()</a>, <a href=
"../functions/fma.html"><i>fma</i>()</a>, <a href="../functions/fmaf.html"><i>fmaf</i>()</a>, <a href=
"../functions/fmal.html"><i>fmal</i>()</a>, <a href="../functions/fmax.html"><i>fmax</i>()</a>, <a href=
"../functions/fmaxf.html"><i>fmaxf</i>()</a>, <a href="../functions/fmaxl.html"><i>fmaxl</i>()</a>, <a href=
"../functions/fmin.html"><i>fmin</i>()</a>, <a href="../functions/fminf.html"><i>fminf</i>()</a>, <a href=
"../functions/fminl.html"><i>fminl</i>()</a>, <a href="../functions/fmod.html"><i>fmod</i>()</a>, <a href=
"../functions/fmodf.html"><i>fmodf</i>()</a>, <a href="../functions/fmodl.html"><i>fmodl</i>()</a>, <a href=
"../functions/fpclassify.html"><i>fpclassify</i>()</a>, <a href="../functions/frexp.html"><i>frexp</i>()</a>, <a href=
"../functions/frexpf.html"><i>frexpf</i>()</a>, <a href="../functions/frexpl.html"><i>frexpl</i>()</a>, <a href=
"../functions/hypot.html"><i>hypot</i>()</a>, <a href="../functions/hypotf.html"><i>hypotf</i>()</a>, <a href=
"../functions/hypotl.html"><i>hypotl</i>()</a>, <a href="../functions/ilogb.html"><i>ilogb</i>()</a>, <a href=
"../functions/ilogbf.html"><i>ilogbf</i>()</a>, <a href="../functions/ilogbl.html"><i>ilogbl</i>()</a>, <a href=
"../functions/isfinite.html"><i>isfinite</i>()</a>, <a href="../functions/isgreater.html"><i>isgreater</i>()</a>, <a href=
"../functions/isgreaterequal.html"><i>isgreaterequal</i>()</a>, <a href="../functions/isinf.html"><i>isinf</i>()</a>, <a href=
"../functions/isless.html"><i>isless</i>()</a>, <a href="../functions/islessequal.html"><i>islessequal</i>()</a>, <a href=
"../functions/islessgreater.html"><i>islessgreater</i>()</a>, <a href="../functions/isnan.html"><i>isnan</i>()</a>, <a href=
"../functions/isnormal.html"><i>isnormal</i>()</a>, <a href="../functions/isunordered.html"><i>isunordered</i>()</a>, <a href=
"../functions/ldexp.html"><i>ldexp</i>()</a>, <a href="../functions/ldexpf.html"><i>ldexpf</i>()</a>, <a href=
"../functions/ldexpl.html"><i>ldexpl</i>()</a>, <a href="../functions/lgamma.html"><i>lgamma</i>()</a>, <a href=
"../functions/lgammaf.html"><i>lgammaf</i>()</a>, <a href="../functions/lgammal.html"><i>lgammal</i>()</a>, <a href=
"../functions/llrint.html"><i>llrint</i>()</a>, <a href="../functions/llrintf.html"><i>llrintf</i>()</a>, <a href=
"../functions/llrintl.html"><i>llrintl</i>()</a>, <a href="../functions/llround.html"><i>llround</i>()</a>, <a href=
"../functions/llroundf.html"><i>llroundf</i>()</a>, <a href="../functions/llroundl.html"><i>llroundl</i>()</a>, <a href=
"../functions/log.html"><i>log</i>()</a>, <a href="../functions/log10.html"><i>log10</i>()</a>, <a href=
"../functions/log10f.html"><i>log10f</i>()</a>, <a href="../functions/log10l.html"><i>log10l</i>()</a>, <a href=
"../functions/log1p.html"><i>log1p</i>()</a>, <a href="../functions/log1pf.html"><i>log1pf</i>()</a>, <a href=
"../functions/log1pl.html"><i>log1pl</i>()</a>, <a href="../functions/log2.html"><i>log2</i>()</a>, <a href=
"../functions/log2f.html"><i>log2f</i>()</a>, <a href="../functions/log2l.html"><i>log2l</i>()</a>, <a href=
"../functions/logb.html"><i>logb</i>()</a>, <a href="../functions/logbf.html"><i>logbf</i>()</a>, <a href=
"../functions/logbl.html"><i>logbl</i>()</a>, <a href="../functions/logf.html"><i>logf</i>()</a>, <a href=
"../functions/logl.html"><i>logl</i>()</a>, <a href="../functions/lrint.html"><i>lrint</i>()</a>, <a href=
"../functions/lrintf.html"><i>lrintf</i>()</a>, <a href="../functions/lrintl.html"><i>lrintl</i>()</a>, <a href=
"../functions/lround.html"><i>lround</i>()</a>, <a href="../functions/lroundf.html"><i>lroundf</i>()</a>, <a href=
"../functions/lroundl.html"><i>lroundl</i>()</a>, <a href="../functions/modf.html"><i>modf</i>()</a>, <a href=
"../functions/modff.html"><i>modff</i>()</a>, <a href="../functions/modfl.html"><i>modfl</i>()</a>, <a href=
"../functions/nan.html"><i>nan</i>()</a>, <a href="../functions/nanf.html"><i>nanf</i>()</a>, <a href=
"../functions/nanl.html"><i>nanl</i>()</a>, <a href="../functions/nearbyint.html"><i>nearbyint</i>()</a>, <a href=
"../functions/nearbyintf.html"><i>nearbyintf</i>()</a>, <a href="../functions/nearbyintl.html"><i>nearbyintl</i>()</a>, <a href=
"../functions/nextafter.html"><i>nextafter</i>()</a>, <a href="../functions/nextafterf.html"><i>nextafterf</i>()</a>, <a href=
"../functions/nextafterl.html"><i>nextafterl</i>()</a>, <a href="../functions/nexttoward.html"><i>nexttoward</i>()</a>, <a href=
"../functions/nexttowardf.html"><i>nexttowardf</i>()</a>, <a href="../functions/nexttowardl.html"><i>nexttowardl</i>()</a>, <a
href="../functions/pow.html"><i>pow</i>()</a>, <a href="../functions/powf.html"><i>powf</i>()</a>, <a href=
"../functions/powl.html"><i>powl</i>()</a>, <a href="../functions/remainder.html"><i>remainder</i>()</a>, <a href=
"../functions/remainderf.html"><i>remainderf</i>()</a>, <a href="../functions/remainderl.html"><i>remainderl</i>()</a>, <a href=
"../functions/remquo.html"><i>remquo</i>()</a>, <a href="../functions/remquof.html"><i>remquof</i>()</a>, <a href=
"../functions/remquol.html"><i>remquol</i>()</a>, <a href="../functions/rint.html"><i>rint</i>()</a>, <a href=
"../functions/rintf.html"><i>rintf</i>()</a>, <a href="../functions/rintl.html"><i>rintl</i>()</a>, <a href=
"../functions/round.html"><i>round</i>()</a>, <a href="../functions/roundf.html"><i>roundf</i>()</a>, <a href=
"../functions/roundl.html"><i>roundl</i>()</a>, <a href="../functions/scalbln.html"><i>scalbln</i>()</a>, <a href=
"../functions/scalblnf.html"><i>scalblnf</i>()</a>, <a href="../functions/scalblnl.html"><i>scalblnl</i>()</a>, <a href=
"../functions/scalbn.html"><i>scalbn</i>()</a>, <a href="../functions/scalbnf.html"><i>scalbnf</i>()</a>, <a href=
"../functions/scalbnl.html"><i>scalbnl</i>()</a>, <a href="../functions/signbit.html"><i>signbit</i>()</a>, <a href=
"../functions/sin.html"><i>sin</i>()</a>, <a href="../functions/sinf.html"><i>sinf</i>()</a>, <a href=
"../functions/sinh.html"><i>sinh</i>()</a>, <a href="../functions/sinhf.html"><i>sinhf</i>()</a>, <a href=
"../functions/sinhl.html"><i>sinhl</i>()</a>, <a href="../functions/sinl.html"><i>sinl</i>()</a>, <a href=
"../functions/sqrt.html"><i>sqrt</i>()</a>, <a href="../functions/sqrtf.html"><i>sqrtf</i>()</a>, <a href=
"../functions/sqrtl.html"><i>sqrtl</i>()</a>, <a href="../functions/tan.html"><i>tan</i>()</a>, <a href=
"../functions/tanf.html"><i>tanf</i>()</a>, <a href="../functions/tanh.html"><i>tanh</i>()</a>, <a href=
"../functions/tanhf.html"><i>tanhf</i>()</a>, <a href="../functions/tanhl.html"><i>tanhl</i>()</a>, <a href=
"../functions/tanl.html"><i>tanl</i>()</a>, <a href="../functions/tgamma.html"><i>tgamma</i>()</a>, <a href=
"../functions/tgammaf.html"><i>tgammaf</i>()</a>, <a href="../functions/tgammal.html"><i>tgammal</i>()</a>, <a href=
"../functions/trunc.html"><i>trunc</i>()</a>, <a href="../functions/truncf.html"><i>truncf</i>()</a>, <a href=
"../functions/truncl.html"><i>truncl</i>()</a></dd>
<dt>POSIX_C_LANG_SUPPORT: General ISO C Library</dt>
<dd>
<a href="../functions/abs.html"><i>abs</i>()</a>, <a href="../functions/asctime.html"><i>asctime</i>()</a>, <a href=
"../functions/atof.html"><i>atof</i>()</a>, <a href="../functions/atoi.html"><i>atoi</i>()</a>, <a href=
"../functions/atol.html"><i>atol</i>()</a>, <a href="../functions/atoll.html"><i>atoll</i>()</a>, <a href=
"../functions/bsearch.html"><i>bsearch</i>()</a>, <a href="../functions/calloc.html"><i>calloc</i>()</a>, <a href=
"../functions/ctime.html"><i>ctime</i>()</a>, <a href="../functions/difftime.html"><i>difftime</i>()</a>, <a href=
"../functions/div.html"><i>div</i>()</a>, <a href="../functions/feclearexcept.html"><i>feclearexcept</i>()</a>, <a href=
"../functions/fegetenv.html"><i>fegetenv</i>()</a>, <a href="../functions/fegetexceptflag.html"><i>fegetexceptflag</i>()</a>, <a
href="../functions/fegetround.html"><i>fegetround</i>()</a>, <a href="../functions/feholdexcept.html"><i>feholdexcept</i>()</a>, <a
href="../functions/feraiseexcept.html"><i>feraiseexcept</i>()</a>, <a href="../functions/fesetenv.html"><i>fesetenv</i>()</a>, <a
href="../functions/fesetexceptflag.html"><i>fesetexceptflag</i>()</a>, <a href=
"../functions/fesetround.html"><i>fesetround</i>()</a>, <a href="../functions/fetestexcept.html"><i>fetestexcept</i>()</a>, <a
href="../functions/feupdateenv.html"><i>feupdateenv</i>()</a>, <a href="../functions/free.html"><i>free</i>()</a>, <a href=
"../functions/gmtime.html"><i>gmtime</i>()</a>, <a href="../functions/imaxabs.html"><i>imaxabs</i>()</a>, <a href=
"../functions/imaxdiv.html"><i>imaxdiv</i>()</a>, <a href="../functions/isalnum.html"><i>isalnum</i>()</a>, <a href=
"../functions/isalpha.html"><i>isalpha</i>()</a>, <a href="../functions/isblank.html"><i>isblank</i>()</a>, <a href=
"../functions/iscntrl.html"><i>iscntrl</i>()</a>, <a href="../functions/isdigit.html"><i>isdigit</i>()</a>, <a href=
"../functions/isgraph.html"><i>isgraph</i>()</a>, <a href="../functions/islower.html"><i>islower</i>()</a>, <a href=
"../functions/isprint.html"><i>isprint</i>()</a>, <a href="../functions/ispunct.html"><i>ispunct</i>()</a>, <a href=
"../functions/isspace.html"><i>isspace</i>()</a>, <a href="../functions/isupper.html"><i>isupper</i>()</a>, <a href=
"../functions/isxdigit.html"><i>isxdigit</i>()</a>, <a href="../functions/labs.html"><i>labs</i>()</a>, <a href=
"../functions/ldiv.html"><i>ldiv</i>()</a>, <a href="../functions/llabs.html"><i>llabs</i>()</a>, <a href=
"../functions/lldiv.html"><i>lldiv</i>()</a>, <a href="../functions/localeconv.html"><i>localeconv</i>()</a>, <a href=
"../functions/localtime.html"><i>localtime</i>()</a>, <a href="../functions/malloc.html"><i>malloc</i>()</a>, <a href=
"../functions/memchr.html"><i>memchr</i>()</a>, <a href="../functions/memcmp.html"><i>memcmp</i>()</a>, <a href=
"../functions/memcpy.html"><i>memcpy</i>()</a>, <a href="../functions/memmove.html"><i>memmove</i>()</a>, <a href=
"../functions/memset.html"><i>memset</i>()</a>, <a href="../functions/mktime.html"><i>mktime</i>()</a>, <a href=
"../functions/qsort.html"><i>qsort</i>()</a>, <a href="../functions/rand.html"><i>rand</i>()</a>, <a href=
"../functions/realloc.html"><i>realloc</i>()</a>, <a href="../functions/setlocale.html"><i>setlocale</i>()</a>, <a href=
"../functions/snprintf.html"><i>snprintf</i>()</a>, <a href="../functions/sprintf.html"><i>sprintf</i>()</a>, <a href=
"../functions/srand.html"><i>srand</i>()</a>, <a href="../functions/sscanf.html"><i>sscanf</i>()</a>, <a href=
"../functions/strcat.html"><i>strcat</i>()</a>, <a href="../functions/strchr.html"><i>strchr</i>()</a>, <a href=
"../functions/strcmp.html"><i>strcmp</i>()</a>, <a href="../functions/strcoll.html"><i>strcoll</i>()</a>, <a href=
"../functions/strcpy.html"><i>strcpy</i>()</a>, <a href="../functions/strcspn.html"><i>strcspn</i>()</a>, <a href=
"../functions/strerror.html"><i>strerror</i>()</a>, <a href="../functions/strftime.html"><i>strftime</i>()</a>, <a href=
"../functions/strlen.html"><i>strlen</i>()</a>, <a href="../functions/strncat.html"><i>strncat</i>()</a>, <a href=
"../functions/strncmp.html"><i>strncmp</i>()</a>, <a href="../functions/strncpy.html"><i>strncpy</i>()</a>, <a href=
"../functions/strpbrk.html"><i>strpbrk</i>()</a>, <a href="../functions/strrchr.html"><i>strrchr</i>()</a>, <a href=
"../functions/strspn.html"><i>strspn</i>()</a>, <a href="../functions/strstr.html"><i>strstr</i>()</a>, <a href=
"../functions/strtod.html"><i>strtod</i>()</a>, <a href="../functions/strtof.html"><i>strtof</i>()</a>, <a href=
"../functions/strtoimax.html"><i>strtoimax</i>()</a>, <a href="../functions/strtok.html"><i>strtok</i>()</a>, <a href=
"../functions/strtol.html"><i>strtol</i>()</a>, <a href="../functions/strtold.html"><i>strtold</i>()</a>, <a href=
"../functions/strtoll.html"><i>strtoll</i>()</a>, <a href="../functions/strtoul.html"><i>strtoul</i>()</a>, <a href=
"../functions/strtoull.html"><i>strtoull</i>()</a>, <a href="../functions/strtoumax.html"><i>strtoumax</i>()</a>, <a href=
"../functions/strxfrm.html"><i>strxfrm</i>()</a>, <a href="../functions/time.html"><i>time</i>()</a>, <a href=
"../functions/tolower.html"><i>tolower</i>()</a>, <a href="../functions/toupper.html"><i>toupper</i>()</a>, <i>tzname</i>, <a href=
"../functions/tzset.html"><i>tzset</i>()</a>, <a href="../functions/va_arg.html"><i>va_arg</i>()</a>, <a href=
"../functions/va_copy.html"><i>va_copy</i>()</a>, <a href="../functions/va_end.html"><i>va_end</i>()</a>, <a href=
"../functions/va_start.html"><i>va_start</i>()</a>, <a href="../functions/vsnprintf.html"><i>vsnprintf</i>()</a>, <a href=
"../functions/vsprintf.html"><i>vsprintf</i>()</a>, <a href="../functions/vsscanf.html"><i>vsscanf</i>()</a></dd>
<dt>POSIX_C_LANG_SUPPORT_R: Thread-Safe General ISO C Library</dt>
<dd>
<a href="../functions/asctime_r.html"><i>asctime_r</i>()</a>, <a href="../functions/ctime_r.html"><i>ctime_r</i>()</a>, <a href=
"../functions/gmtime_r.html"><i>gmtime_r</i>()</a>, <a href="../functions/localtime_r.html"><i>localtime_r</i>()</a>, <a href=
"../functions/rand_r.html"><i>rand_r</i>()</a>, <a href="../functions/strerror_r.html"><i>strerror_r</i>()</a>, <a href=
"../functions/strtok_r.html"><i>strtok_r</i>()</a></dd>
<dt>POSIX_C_LANG_WIDE_CHAR: Wide-Character ISO C Library</dt>
<dd>
<a href="../functions/btowc.html"><i>btowc</i>()</a>, <a href="../functions/iswalnum.html"><i>iswalnum</i>()</a>, <a href=
"../functions/iswalpha.html"><i>iswalpha</i>()</a>, <a href="../functions/iswblank.html"><i>iswblank</i>()</a>, <a href=
"../functions/iswcntrl.html"><i>iswcntrl</i>()</a>, <a href="../functions/iswctype.html"><i>iswctype</i>()</a>, <a href=
"../functions/iswdigit.html"><i>iswdigit</i>()</a>, <a href="../functions/iswgraph.html"><i>iswgraph</i>()</a>, <a href=
"../functions/iswlower.html"><i>iswlower</i>()</a>, <a href="../functions/iswprint.html"><i>iswprint</i>()</a>, <a href=
"../functions/iswpunct.html"><i>iswpunct</i>()</a>, <a href="../functions/iswspace.html"><i>iswspace</i>()</a>, <a href=
"../functions/iswupper.html"><i>iswupper</i>()</a>, <a href="../functions/iswxdigit.html"><i>iswxdigit</i>()</a>, <a href=
"../functions/mblen.html"><i>mblen</i>()</a>, <a href="../functions/mbrlen.html"><i>mbrlen</i>()</a>, <a href=
"../functions/mbrtowc.html"><i>mbrtowc</i>()</a>, <a href="../functions/mbsinit.html"><i>mbsinit</i>()</a>, <a href=
"../functions/mbsrtowcs.html"><i>mbsrtowcs</i>()</a>, <a href="../functions/mbstowcs.html"><i>mbstowcs</i>()</a>, <a href=
"../functions/mbtowc.html"><i>mbtowc</i>()</a>, <a href="../functions/swprintf.html"><i>swprintf</i>()</a>, <a href=
"../functions/swscanf.html"><i>swscanf</i>()</a>, <a href="../functions/towctrans.html"><i>towctrans</i>()</a>, <a href=
"../functions/towlower.html"><i>towlower</i>()</a>, <a href="../functions/towupper.html"><i>towupper</i>()</a>, <a href=
"../functions/vswprintf.html"><i>vswprintf</i>()</a>, <a href="../functions/vswscanf.html"><i>vswscanf</i>()</a>, <a href=
"../functions/wcrtomb.html"><i>wcrtomb</i>()</a>, <a href="../functions/wcscat.html"><i>wcscat</i>()</a>, <a href=
"../functions/wcschr.html"><i>wcschr</i>()</a>, <a href="../functions/wcscmp.html"><i>wcscmp</i>()</a>, <a href=
"../functions/wcscoll.html"><i>wcscoll</i>()</a>, <a href="../functions/wcscpy.html"><i>wcscpy</i>()</a>, <a href=
"../functions/wcscspn.html"><i>wcscspn</i>()</a>, <a href="../functions/wcsftime.html"><i>wcsftime</i>()</a>, <a href=
"../functions/wcslen.html"><i>wcslen</i>()</a>, <a href="../functions/wcsncat.html"><i>wcsncat</i>()</a>, <a href=
"../functions/wcsncmp.html"><i>wcsncmp</i>()</a>, <a href="../functions/wcsncpy.html"><i>wcsncpy</i>()</a>, <a href=
"../functions/wcspbrk.html"><i>wcspbrk</i>()</a>, <a href="../functions/wcsrchr.html"><i>wcsrchr</i>()</a>, <a href=
"../functions/wcsrtombs.html"><i>wcsrtombs</i>()</a>, <a href="../functions/wcsspn.html"><i>wcsspn</i>()</a>, <a href=
"../functions/wcsstr.html"><i>wcsstr</i>()</a>, <a href="../functions/wcstod.html"><i>wcstod</i>()</a>, <a href=
"../functions/wcstof.html"><i>wcstof</i>()</a>, <a href="../functions/wcstoimax.html"><i>wcstoimax</i>()</a>, <a href=
"../functions/wcstok.html"><i>wcstok</i>()</a>, <a href="../functions/wcstol.html"><i>wcstol</i>()</a>, <a href=
"../functions/wcstold.html"><i>wcstold</i>()</a>, <a href="../functions/wcstoll.html"><i>wcstoll</i>()</a>, <a href=
"../functions/wcstombs.html"><i>wcstombs</i>()</a>, <a href="../functions/wcstoul.html"><i>wcstoul</i>()</a>, <a href=
"../functions/wcstoull.html"><i>wcstoull</i>()</a>, <a href="../functions/wcstoumax.html"><i>wcstoumax</i>()</a>, <a href=
"../functions/wcsxfrm.html"><i>wcsxfrm</i>()</a>, <a href="../functions/wctob.html"><i>wctob</i>()</a>, <a href=
"../functions/wctomb.html"><i>wctomb</i>()</a>, <a href="../functions/wctrans.html"><i>wctrans</i>()</a>, <a href=
"../functions/wctype.html"><i>wctype</i>()</a>, <a href="../functions/wmemchr.html"><i>wmemchr</i>()</a>, <a href=
"../functions/wmemcmp.html"><i>wmemcmp</i>()</a>, <a href="../functions/wmemcpy.html"><i>wmemcpy</i>()</a>, <a href=
"../functions/wmemmove.html"><i>wmemmove</i>()</a>, <a href="../functions/wmemset.html"><i>wmemset</i>()</a></dd>
<dt>POSIX_C_LIB_EXT: General C Library Extension</dt>
<dd>
<a href="../functions/fnmatch.html"><i>fnmatch</i>()</a>, <a href="../functions/getopt.html"><i>getopt</i>()</a>, <i>optarg</i>,
<i>opterr</i>, <i>optind</i>, <i>optopt</i></dd>
<dt>POSIX_DEVICE_IO: Device Input and Output</dt>
<dd>
<a href="../functions/FD_CLR.html"><i>FD_CLR</i>()</a>, <a href="../functions/FD_ISSET.html"><i>FD_ISSET</i>()</a>, <a href=
"../functions/FD_SET.html"><i>FD_SET</i>()</a>, <a href="../functions/FD_ZERO.html"><i>FD_ZERO</i>()</a>, <a href=
"../functions/clearerr.html"><i>clearerr</i>()</a>, <a href="../functions/close.html"><i>close</i>()</a>, <a href=
"../functions/fclose.html"><i>fclose</i>()</a>, <a href="../functions/fdopen.html"><i>fdopen</i>()</a>, <a href=
"../functions/feof.html"><i>feof</i>()</a>, <a href="../functions/ferror.html"><i>ferror</i>()</a>, <a href=
"../functions/fflush.html"><i>fflush</i>()</a>, <a href="../functions/fgetc.html"><i>fgetc</i>()</a>, <a href=
"../functions/fgets.html"><i>fgets</i>()</a>, <a href="../functions/fileno.html"><i>fileno</i>()</a>, <a href=
"../functions/fopen.html"><i>fopen</i>()</a>, <a href="../functions/fprintf.html"><i>fprintf</i>()</a>, <a href=
"../functions/fputc.html"><i>fputc</i>()</a>, <a href="../functions/fputs.html"><i>fputs</i>()</a>, <a href=
"../functions/fread.html"><i>fread</i>()</a>, <a href="../functions/freopen.html"><i>freopen</i>()</a>, <a href=
"../functions/fscanf.html"><i>fscanf</i>()</a>, <a href="../functions/fwrite.html"><i>fwrite</i>()</a>, <a href=
"../functions/getc.html"><i>getc</i>()</a>, <a href="../functions/getchar.html"><i>getchar</i>()</a>, <a href=
"../functions/gets.html"><i>gets</i>()</a>, <a href="../functions/open.html"><i>open</i>()</a>, <a href=
"../functions/perror.html"><i>perror</i>()</a>, <a href="../functions/printf.html"><i>printf</i>()</a>, <a href=
"../functions/pselect.html"><i>pselect</i>()</a>, <a href="../functions/putc.html"><i>putc</i>()</a>, <a href=
"../functions/putchar.html"><i>putchar</i>()</a>, <a href="../functions/puts.html"><i>puts</i>()</a>, <a href=
"../functions/read.html"><i>read</i>()</a>, <a href="../functions/scanf.html"><i>scanf</i>()</a>, <a href=
"../functions/select.html"><i>select</i>()</a>, <a href="../functions/setbuf.html"><i>setbuf</i>()</a>, <a href=
"../functions/setvbuf.html"><i>setvbuf</i>()</a>, <i>stderr</i>, <i>stdin</i>, <i>stdout</i>, <a href=
"../functions/ungetc.html"><i>ungetc</i>()</a>, <a href="../functions/vfprintf.html"><i>vfprintf</i>()</a>, <a href=
"../functions/vfscanf.html"><i>vfscanf</i>()</a>, <a href="../functions/vprintf.html"><i>vprintf</i>()</a>, <a href=
"../functions/vscanf.html"><i>vscanf</i>()</a>, <a href="../functions/write.html"><i>write</i>()</a></dd>
<dt>POSIX_DEVICE_SPECIFIC: General Terminal</dt>
<dd>
<a href="../functions/cfgetispeed.html"><i>cfgetispeed</i>()</a>, <a href="../functions/cfgetospeed.html"><i>cfgetospeed</i>()</a>,
<a href="../functions/cfsetispeed.html"><i>cfsetispeed</i>()</a>, <a href="../functions/cfsetospeed.html"><i>cfsetospeed</i>()</a>,
<a href="../functions/ctermid.html"><i>ctermid</i>()</a>, <a href="../functions/isatty.html"><i>isatty</i>()</a>, <a href=
"../functions/tcdrain.html"><i>tcdrain</i>()</a>, <a href="../functions/tcflow.html"><i>tcflow</i>()</a>, <a href=
"../functions/tcflush.html"><i>tcflush</i>()</a>, <a href="../functions/tcgetattr.html"><i>tcgetattr</i>()</a>, <a href=
"../functions/tcsendbreak.html"><i>tcsendbreak</i>()</a>, <a href="../functions/tcsetattr.html"><i>tcsetattr</i>()</a>, <a href=
"../functions/ttyname.html"><i>ttyname</i>()</a></dd>
<dt>POSIX_DEVICE_SPECIFIC_R: Thread-Safe General Terminal</dt>
<dd>
<a href="../functions/ttyname_r.html"><i>ttyname_r</i>()</a></dd>
<dt>POSIX_FD_MGMT: File Descriptor Management</dt>
<dd>
<a href="../functions/dup.html"><i>dup</i>()</a>, <a href="../functions/dup2.html"><i>dup2</i>()</a>, <a href=
"../functions/fcntl.html"><i>fcntl</i>()</a>, <a href="../functions/fgetpos.html"><i>fgetpos</i>()</a>, <a href=
"../functions/fseek.html"><i>fseek</i>()</a>, <a href="../functions/fseeko.html"><i>fseeko</i>()</a>, <a href=
"../functions/fsetpos.html"><i>fsetpos</i>()</a>, <a href="../functions/ftell.html"><i>ftell</i>()</a>, <a href=
"../functions/ftello.html"><i>ftello</i>()</a>, <a href="../functions/ftruncate.html"><i>ftruncate</i>()</a>, <a href=
"../functions/lseek.html"><i>lseek</i>()</a>, <a href="../functions/rewind.html"><i>rewind</i>()</a></dd>
<dt>POSIX_FIFO: FIFO</dt>
<dd>
<a href="../functions/mkfifo.html"><i>mkfifo</i>()</a></dd>
<dt>POSIX_FILE_ATTRIBUTES: File Attributes</dt>
<dd>
<a href="../functions/chmod.html"><i>chmod</i>()</a>, <a href="../functions/chown.html"><i>chown</i>()</a>, <a href=
"../functions/fchmod.html"><i>fchmod</i>()</a>, <a href="../functions/fchown.html"><i>fchown</i>()</a>, <a href=
"../functions/umask.html"><i>umask</i>()</a></dd>
<dt>POSIX_FILE_LOCKING: Thread-Safe Stdio Locking</dt>
<dd>
<a href="../functions/flockfile.html"><i>flockfile</i>()</a>, <a href="../functions/ftrylockfile.html"><i>ftrylockfile</i>()</a>,
<a href="../functions/funlockfile.html"><i>funlockfile</i>()</a>, <a href=
"../functions/getc_unlocked.html"><i>getc_unlocked</i>()</a>, <a href=
"../functions/getchar_unlocked.html"><i>getchar_unlocked</i>()</a>, <a href=
"../functions/putc_unlocked.html"><i>putc_unlocked</i>()</a>, <a href=
"../functions/putchar_unlocked.html"><i>putchar_unlocked</i>()</a></dd>
<dt>POSIX_FILE_SYSTEM: File System</dt>
<dd>
<a href="../functions/access.html"><i>access</i>()</a>, <a href="../functions/chdir.html"><i>chdir</i>()</a>, <a href=
"../functions/closedir.html"><i>closedir</i>()</a>, <a href="../functions/creat.html"><i>creat</i>()</a>, <a href=
"../functions/fpathconf.html"><i>fpathconf</i>()</a>, <a href="../functions/fstat.html"><i>fstat</i>()</a>, <a href=
"../functions/getcwd.html"><i>getcwd</i>()</a>, <a href="../functions/link.html"><i>link</i>()</a>, <a href=
"../functions/mkdir.html"><i>mkdir</i>()</a>, <a href="../functions/opendir.html"><i>opendir</i>()</a>, <a href=
"../functions/pathconf.html"><i>pathconf</i>()</a>, <a href="../functions/readdir.html"><i>readdir</i>()</a>, <a href=
"../functions/remove.html"><i>remove</i>()</a>, <a href="../functions/rename.html"><i>rename</i>()</a>, <a href=
"../functions/rewinddir.html"><i>rewinddir</i>()</a>, <a href="../functions/rmdir.html"><i>rmdir</i>()</a>, <a href=
"../functions/stat.html"><i>stat</i>()</a>, <a href="../functions/tmpfile.html"><i>tmpfile</i>()</a>, <a href=
"../functions/tmpnam.html"><i>tmpnam</i>()</a>, <a href="../functions/unlink.html"><i>unlink</i>()</a>, <a href=
"../functions/utime.html"><i>utime</i>()</a></dd>
<dt>POSIX_FILE_SYSTEM_EXT: File System Extensions</dt>
<dd>
<a href="../functions/glob.html"><i>glob</i>()</a>, <a href="../functions/globfree.html"><i>globfree</i>()</a></dd>
<dt>POSIX_FILE_SYSTEM_R: Thread-Safe File System</dt>
<dd>
<a href="../functions/readdir_r.html"><i>readdir_r</i>()</a></dd>
<dt>POSIX_JOB_CONTROL: Job Control</dt>
<dd>
<a href="../functions/setpgid.html"><i>setpgid</i>()</a>, <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>, <a href=
"../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a></dd>
<dt>POSIX_MULTI_PROCESS: Multiple Processes</dt>
<dd>
<a href="../functions/_Exit.html"><i>_Exit</i>()</a>, <a href="../functions/_exit.html"><i>_exit</i>()</a>, <a href=
"../functions/assert.html"><i>assert</i>()</a>, <a href="../functions/atexit.html"><i>atexit</i>()</a>, <a href=
"../functions/clock.html"><i>clock</i>()</a>, <a href="../functions/execl.html"><i>execl</i>()</a>, <a href=
"../functions/execle.html"><i>execle</i>()</a>, <a href="../functions/execlp.html"><i>execlp</i>()</a>, <a href=
"../functions/execv.html"><i>execv</i>()</a>, <a href="../functions/execve.html"><i>execve</i>()</a>, <a href=
"../functions/execvp.html"><i>execvp</i>()</a>, <a href="../functions/exit.html"><i>exit</i>()</a>, <a href=
"../functions/fork.html"><i>fork</i>()</a>, <a href="../functions/getpgrp.html"><i>getpgrp</i>()</a>, <a href=
"../functions/getpid.html"><i>getpid</i>()</a>, <a href="../functions/getppid.html"><i>getppid</i>()</a>, <a href=
"../functions/setsid.html"><i>setsid</i>()</a>, <a href="../functions/sleep.html"><i>sleep</i>()</a>, <a href=
"../functions/times.html"><i>times</i>()</a>, <a href="../functions/wait.html"><i>wait</i>()</a>, <a href=
"../functions/waitpid.html"><i>waitpid</i>()</a></dd>
<dt>POSIX_NETWORKING: Networking</dt>
<dd>
<a href="../functions/accept.html"><i>accept</i>()</a>, <a href="../functions/bind.html"><i>bind</i>()</a>, <a href=
"../functions/connect.html"><i>connect</i>()</a>, <a href="../functions/endhostent.html"><i>endhostent</i>()</a>, <a href=
"../functions/endnetent.html"><i>endnetent</i>()</a>, <a href="../functions/endprotoent.html"><i>endprotoent</i>()</a>, <a href=
"../functions/endservent.html"><i>endservent</i>()</a>, <a href="../functions/freeaddrinfo.html"><i>freeaddrinfo</i>()</a>, <a
href="../functions/gai_strerror.html"><i>gai_strerror</i>()</a>, <a href="../functions/getaddrinfo.html"><i>getaddrinfo</i>()</a>,
<a href="../functions/gethostbyaddr.html"><i>gethostbyaddr</i>()</a>, <a href=
"../functions/gethostbyname.html"><i>gethostbyname</i>()</a>, <a href="../functions/gethostent.html"><i>gethostent</i>()</a>, <a
href="../functions/gethostname.html"><i>gethostname</i>()</a>, <a href="../functions/getnameinfo.html"><i>getnameinfo</i>()</a>, <a
href="../functions/getnetbyaddr.html"><i>getnetbyaddr</i>()</a>, <a href=
"../functions/getnetbyname.html"><i>getnetbyname</i>()</a>, <a href="../functions/getnetent.html"><i>getnetent</i>()</a>, <a href=
"../functions/getpeername.html"><i>getpeername</i>()</a>, <a href="../functions/getprotobyname.html"><i>getprotobyname</i>()</a>,
<a href="../functions/getprotobynumber.html"><i>getprotobynumber</i>()</a>, <a href=
"../functions/getprotoent.html"><i>getprotoent</i>()</a>, <a href="../functions/getservbyname.html"><i>getservbyname</i>()</a>, <a
href="../functions/getservbyport.html"><i>getservbyport</i>()</a>, <a href="../functions/getservent.html"><i>getservent</i>()</a>,
<a href="../functions/getsockname.html"><i>getsockname</i>()</a>, <a href="../functions/getsockopt.html"><i>getsockopt</i>()</a>,
<i>h_errno</i>, <a href="../functions/htonl.html"><i>htonl</i>()</a>, <a href="../functions/htons.html"><i>htons</i>()</a>, <a
href="../functions/if_freenameindex.html"><i>if_freenameindex</i>()</a>, <a href=
"../functions/if_indextoname.html"><i>if_indextoname</i>()</a>, <a href="../functions/if_nameindex.html"><i>if_nameindex</i>()</a>,
<a href="../functions/if_nametoindex.html"><i>if_nametoindex</i>()</a>, <a href=
"../functions/inet_addr.html"><i>inet_addr</i>()</a>, <a href="../functions/inet_ntoa.html"><i>inet_ntoa</i>()</a>, <a href=
"../functions/inet_ntop.html"><i>inet_ntop</i>()</a>, <a href="../functions/inet_pton.html"><i>inet_pton</i>()</a>, <a href=
"../functions/listen.html"><i>listen</i>()</a>, <a href="../functions/ntohl.html"><i>ntohl</i>()</a>, <a href=
"../functions/ntohs.html"><i>ntohs</i>()</a>, <a href="../functions/recv.html"><i>recv</i>()</a>, <a href=
"../functions/recvfrom.html"><i>recvfrom</i>()</a>, <a href="../functions/recvmsg.html"><i>recvmsg</i>()</a>, <a href=
"../functions/send.html"><i>send</i>()</a>, <a href="../functions/sendmsg.html"><i>sendmsg</i>()</a>, <a href=
"../functions/sendto.html"><i>sendto</i>()</a>, <a href="../functions/sethostent.html"><i>sethostent</i>()</a>, <a href=
"../functions/setnetent.html"><i>setnetent</i>()</a>, <a href="../functions/setprotoent.html"><i>setprotoent</i>()</a>, <a href=
"../functions/setservent.html"><i>setservent</i>()</a>, <a href="../functions/setsockopt.html"><i>setsockopt</i>()</a>, <a href=
"../functions/shutdown.html"><i>shutdown</i>()</a>, <a href="../functions/socket.html"><i>socket</i>()</a>, <a href=
"../functions/sockatmark.html"><i>sockatmark</i>()</a>, <a href="../functions/socketpair.html"><i>socketpair</i>()</a></dd>
<dt>POSIX_PIPE: Pipe</dt>
<dd>
<a href="../functions/pipe.html"><i>pipe</i>()</a></dd>
<dt>POSIX_REGEXP: Regular Expressions</dt>
<dd>
<a href="../functions/regcomp.html"><i>regcomp</i>()</a>, <a href="../functions/regerror.html"><i>regerror</i>()</a>, <a href=
"../functions/regexec.html"><i>regexec</i>()</a>, <a href="../functions/regfree.html"><i>regfree</i>()</a></dd>
<dt>POSIX_SHELL_FUNC: Shell and Utilities</dt>
<dd>
<a href="../functions/pclose.html"><i>pclose</i>()</a>, <a href="../functions/popen.html"><i>popen</i>()</a>, <a href=
"../functions/system.html"><i>system</i>()</a>, <a href="../functions/wordexp.html"><i>wordexp</i>()</a>, <a href=
"../functions/wordfree.html"><i>wordfree</i>()</a></dd>
<dt>POSIX_SIGNALS: Signal</dt>
<dd>
<a href="../functions/abort.html"><i>abort</i>()</a>, <a href="../functions/alarm.html"><i>alarm</i>()</a>, <a href=
"../functions/kill.html"><i>kill</i>()</a>, <a href="../functions/pause.html"><i>pause</i>()</a>, <a href=
"../functions/raise.html"><i>raise</i>()</a>, <a href="../functions/sigaction.html"><i>sigaction</i>()</a>, <a href=
"../functions/sigaddset.html"><i>sigaddset</i>()</a>, <a href="../functions/sigdelset.html"><i>sigdelset</i>()</a>, <a href=
"../functions/sigemptyset.html"><i>sigemptyset</i>()</a>, <a href="../functions/sigfillset.html"><i>sigfillset</i>()</a>, <a href=
"../functions/sigismember.html"><i>sigismember</i>()</a>, <a href="../functions/signal.html"><i>signal</i>()</a>, <a href=
"../functions/sigpending.html"><i>sigpending</i>()</a>, <a href="../functions/sigprocmask.html"><i>sigprocmask</i>()</a>, <a href=
"../functions/sigsuspend.html"><i>sigsuspend</i>()</a>, <a href="../functions/sigwait.html"><i>sigwait</i>()</a></dd>
<dt>POSIX_SIGNAL_JUMP: Signal Jump Functions</dt>
<dd>
<a href="../functions/siglongjmp.html"><i>siglongjmp</i>()</a>, <a href="../functions/sigsetjmp.html"><i>sigsetjmp</i>()</a></dd>
<dt>POSIX_SINGLE_PROCESS: Single Process</dt>
<dd>
<a href="../functions/confstr.html"><i>confstr</i>()</a>, <i>environ</i>, <i>errno</i>, <a href=
"../functions/getenv.html"><i>getenv</i>()</a>, <a href="../functions/setenv.html"><i>setenv</i>()</a>, <a href=
"../functions/sysconf.html"><i>sysconf</i>()</a>, <a href="../functions/uname.html"><i>uname</i>()</a>, <a href=
"../functions/unsetenv.html"><i>unsetenv</i>()</a></dd>
<dt>POSIX_SYMBOLIC_LINKS: Symbolic Links</dt>
<dd>
<a href="../functions/lstat.html"><i>lstat</i>()</a>, <a href="../functions/readlink.html"><i>readlink</i>()</a>, <a href=
"../functions/symlink.html"><i>symlink</i>()</a></dd>
<dt>POSIX_SYSTEM_DATABASE: System Database</dt>
<dd>
<a href="../functions/getgrgid.html"><i>getgrgid</i>()</a>, <a href="../functions/getgrnam.html"><i>getgrnam</i>()</a>, <a href=
"../functions/getpwnam.html"><i>getpwnam</i>()</a>, <a href="../functions/getpwuid.html"><i>getpwuid</i>()</a></dd>
<dt>POSIX_SYSTEM_DATABASE_R: Thread-Safe System Database</dt>
<dd>
<a href="../functions/getgrgid_r.html"><i>getgrgid_r</i>()</a>, <a href="../functions/getgrnam_r.html"><i>getgrnam_r</i>()</a>, <a
href="../functions/getpwnam_r.html"><i>getpwnam_r</i>()</a>, <a href="../functions/getpwuid_r.html"><i>getpwuid_r</i>()</a></dd>
<dt>POSIX_USER_GROUPS: User and Group</dt>
<dd>
<a href="../functions/getegid.html"><i>getegid</i>()</a>, <a href="../functions/geteuid.html"><i>geteuid</i>()</a>, <a href=
"../functions/getgid.html"><i>getgid</i>()</a>, <a href="../functions/getgroups.html"><i>getgroups</i>()</a>, <a href=
"../functions/getlogin.html"><i>getlogin</i>()</a>, <a href="../functions/getuid.html"><i>getuid</i>()</a>, <a href=
"../functions/setegid.html"><i>setegid</i>()</a>, <a href="../functions/seteuid.html"><i>seteuid</i>()</a>, <a href=
"../functions/setgid.html"><i>setgid</i>()</a>, <a href="../functions/setuid.html"><i>setuid</i>()</a></dd>
<dt>POSIX_USER_GROUPS_R: Thread-Safe User and Group</dt>
<dd>
<a href="../functions/getlogin_r.html"><i>getlogin_r</i>()</a></dd>
<dt>POSIX_WIDE_CHAR_DEVICE_IO: Device Input and Output</dt>
<dd>
<a href="../functions/fgetwc.html"><i>fgetwc</i>()</a>, <a href="../functions/fgetws.html"><i>fgetws</i>()</a>, <a href=
"../functions/fputwc.html"><i>fputwc</i>()</a>, <a href="../functions/fputws.html"><i>fputws</i>()</a>, <a href=
"../functions/fwide.html"><i>fwide</i>()</a>, <a href="../functions/fwprintf.html"><i>fwprintf</i>()</a>, <a href=
"../functions/fwscanf.html"><i>fwscanf</i>()</a>, <a href="../functions/getwc.html"><i>getwc</i>()</a>, <a href=
"../functions/getwchar.html"><i>getwchar</i>()</a>, <a href="../functions/putwc.html"><i>putwc</i>()</a>, <a href=
"../functions/putwchar.html"><i>putwchar</i>()</a>, <a href="../functions/ungetwc.html"><i>ungetwc</i>()</a>, <a href=
"../functions/vfwprintf.html"><i>vfwprintf</i>()</a>, <a href="../functions/vfwscanf.html"><i>vfwscanf</i>()</a>, <a href=
"../functions/vwprintf.html"><i>vwprintf</i>()</a>, <a href="../functions/vwscanf.html"><i>vwscanf</i>()</a>, <a href=
"../functions/wprintf.html"><i>wprintf</i>()</a>, <a href="../functions/wscanf.html"><i>wscanf</i>()</a></dd>
<dt>XSI_C_LANG_SUPPORT: XSI General C Library</dt>
<dd>
<a href="../functions/_tolower.html"><i>_tolower</i>()</a>, <a href="../functions/_toupper.html"><i>_toupper</i>()</a>, <a href=
"../functions/a64l.html"><i>a64l</i>()</a>, <a href="../functions/daylight.html"><i>daylight</i>()</a>, <a href=
"../functions/drand48.html"><i>drand48</i>()</a>, <a href="../functions/erand48.html"><i>erand48</i>()</a>, <a href=
"../functions/ffs.html"><i>ffs</i>()</a>, <a href="../functions/getcontext.html"><i>getcontext</i>()</a>, <a href=
"../functions/getdate.html"><i>getdate</i>()</a>, <a href="../functions/getsubopt.html"><i>getsubopt</i>()</a>, <a href=
"../functions/hcreate.html"><i>hcreate</i>()</a>, <a href="../functions/hdestroy.html"><i>hdestroy</i>()</a>, <a href=
"../functions/hsearch.html"><i>hsearch</i>()</a>, <a href="../functions/iconv.html"><i>iconv</i>()</a>, <a href=
"../functions/iconv_close.html"><i>iconv_close</i>()</a>, <a href="../functions/iconv_open.html"><i>iconv_open</i>()</a>, <a href=
"../functions/initstate.html"><i>initstate</i>()</a>, <a href="../functions/insque.html"><i>insque</i>()</a>, <a href=
"../functions/isascii.html"><i>isascii</i>()</a>, <a href="../functions/jrand48.html"><i>jrand48</i>()</a>, <a href=
"../functions/l64a.html"><i>l64a</i>()</a>, <a href="../functions/lcong48.html"><i>lcong48</i>()</a>, <a href=
"../functions/lfind.html"><i>lfind</i>()</a>, <a href="../functions/lrand48.html"><i>lrand48</i>()</a>, <a href=
"../functions/lsearch.html"><i>lsearch</i>()</a>, <a href="../functions/makecontext.html"><i>makecontext</i>()</a>, <a href=
"../functions/memccpy.html"><i>memccpy</i>()</a>, <a href="../functions/mrand48.html"><i>mrand48</i>()</a>, <a href=
"../functions/nrand48.html"><i>nrand48</i>()</a>, <a href="../functions/random.html"><i>random</i>()</a>, <a href=
"../functions/remque.html"><i>remque</i>()</a>, <a href="../functions/seed48.html"><i>seed48</i>()</a>, <a href=
"../functions/setcontext.html"><i>setcontext</i>()</a>, <a href="../functions/setstate.html"><i>setstate</i>()</a>, <i>signgam</i>,
<a href="../functions/srand48.html"><i>srand48</i>()</a>, <a href="../functions/srandom.html"><i>srandom</i>()</a>, <a href=
"../functions/strcasecmp.html"><i>strcasecmp</i>()</a>, <a href="../functions/strdup.html"><i>strdup</i>()</a>, <a href=
"../functions/strfmon.html"><i>strfmon</i>()</a>, <a href="../functions/strncasecmp.html"><i>strncasecmp</i>()</a>, <a href=
"../functions/strptime.html"><i>strptime</i>()</a>, <a href="../functions/swab.html"><i>swab</i>()</a>, <a href=
"../functions/swapcontext.html"><i>swapcontext</i>()</a>, <a href="../functions/tdelete.html"><i>tdelete</i>()</a>, <a href=
"../functions/tfind.html"><i>tfind</i>()</a>, <a href="../functions/timezone.html"><i>timezone</i>()</a>, <a href=
"../functions/toascii.html"><i>toascii</i>()</a>, <a href="../functions/tsearch.html"><i>tsearch</i>()</a>, <a href=
"../functions/twalk.html"><i>twalk</i>()</a></dd>
<dt>XSI_DBM: XSI Database Management</dt>
<dd>
<a href="../functions/dbm_clearerr.html"><i>dbm_clearerr</i>()</a>, <a href="../functions/dbm_close.html"><i>dbm_close</i>()</a>,
<a href="../functions/dbm_delete.html"><i>dbm_delete</i>()</a>, <a href="../functions/dbm_error.html"><i>dbm_error</i>()</a>, <a
href="../functions/dbm_fetch.html"><i>dbm_fetch</i>()</a>, <a href="../functions/dbm_firstkey.html"><i>dbm_firstkey</i>()</a>, <a
href="../functions/dbm_nextkey.html"><i>dbm_nextkey</i>()</a>, <a href="../functions/dbm_open.html"><i>dbm_open</i>()</a>, <a href=
"../functions/dbm_store.html"><i>dbm_store</i>()</a></dd>
<dt>XSI_DEVICE_IO: XSI Device Input and Output</dt>
<dd>
<a href="../functions/fmtmsg.html"><i>fmtmsg</i>()</a>, <a href="../functions/poll.html"><i>poll</i>()</a>, <a href=
"../functions/pread.html"><i>pread</i>()</a>, <a href="../functions/pwrite.html"><i>pwrite</i>()</a>, <a href=
"../functions/readv.html"><i>readv</i>()</a>, <a href="../functions/writev.html"><i>writev</i>()</a></dd>
<dt>XSI_DEVICE_SPECIFIC: XSI General Terminal</dt>
<dd>
<a href="../functions/grantpt.html"><i>grantpt</i>()</a>, <a href="../functions/posix_openpt.html"><i>posix_openpt</i>()</a>, <a
href="../functions/ptsname.html"><i>ptsname</i>()</a>, <a href="../functions/unlockpt.html"><i>unlockpt</i>()</a></dd>
<dt>XSI_DYNAMIC_LINKING: XSI Dynamic Linking</dt>
<dd>
<a href="../functions/dlclose.html"><i>dlclose</i>()</a>, <a href="../functions/dlerror.html"><i>dlerror</i>()</a>, <a href=
"../functions/dlopen.html"><i>dlopen</i>()</a>, <a href="../functions/dlsym.html"><i>dlsym</i>()</a></dd>
<dt>XSI_FD_MGMT: XSI File Descriptor Management</dt>
<dd>
<a href="../functions/truncate.html"><i>truncate</i>()</a></dd>
<dt>XSI_FILE_SYSTEM: XSI File System</dt>
<dd>
<a href="../functions/basename.html"><i>basename</i>()</a>, <a href="../functions/dirname.html"><i>dirname</i>()</a>, <a href=
"../functions/fchdir.html"><i>fchdir</i>()</a>, <a href="../functions/fstatvfs.html"><i>fstatvfs</i>()</a>, <a href=
"../functions/ftw.html"><i>ftw</i>()</a>, <a href="../functions/lchown.html"><i>lchown</i>()</a>, <a href=
"../functions/lockf.html"><i>lockf</i>()</a>, <a href="../functions/mknod.html"><i>mknod</i>()</a>, <a href=
"../functions/mkstemp.html"><i>mkstemp</i>()</a>, <a href="../functions/nftw.html"><i>nftw</i>()</a>, <a href=
"../functions/realpath.html"><i>realpath</i>()</a>, <a href="../functions/seekdir.html"><i>seekdir</i>()</a>, <a href=
"../functions/statvfs.html"><i>statvfs</i>()</a>, <a href="../functions/sync.html"><i>sync</i>()</a>, <a href=
"../functions/telldir.html"><i>telldir</i>()</a>, <a href="../functions/tempnam.html"><i>tempnam</i>()</a></dd>
<dt>XSI_I18N: XSI Internationalization</dt>
<dd>
<a href="../functions/catclose.html"><i>catclose</i>()</a>, <a href="../functions/catgets.html"><i>catgets</i>()</a>, <a href=
"../functions/catopen.html"><i>catopen</i>()</a>, <a href="../functions/nl_langinfo.html"><i>nl_langinfo</i>()</a></dd>
<dt>XSI_IPC: XSI Interprocess Communication</dt>
<dd>
<a href="../functions/ftok.html"><i>ftok</i>()</a>, <a href="../functions/msgctl.html"><i>msgctl</i>()</a>, <a href=
"../functions/msgget.html"><i>msgget</i>()</a>, <a href="../functions/msgrcv.html"><i>msgrcv</i>()</a>, <a href=
"../functions/msgsnd.html"><i>msgsnd</i>()</a>, <a href="../functions/semctl.html"><i>semctl</i>()</a>, <a href=
"../functions/semget.html"><i>semget</i>()</a>, <a href="../functions/semop.html"><i>semop</i>()</a>, <a href=
"../functions/shmat.html"><i>shmat</i>()</a>, <a href="../functions/shmctl.html"><i>shmctl</i>()</a>, <a href=
"../functions/shmdt.html"><i>shmdt</i>()</a>, <a href="../functions/shmget.html"><i>shmget</i>()</a></dd>
<dt>XSI_JOB_CONTROL: XSI Job Control</dt>
<dd>
<a href="../functions/tcgetsid.html"><i>tcgetsid</i>()</a></dd>
<dt>XSI_JUMP: XSI Jump Functions</dt>
<dd>
<a href="../functions/_longjmp.html"><i>_longjmp</i>()</a>, <a href="../functions/_setjmp.html"><i>_setjmp</i>()</a></dd>
<dt>XSI_MATH: XSI Maths Library</dt>
<dd>
<a href="../functions/j0.html"><i>j0</i>()</a>, <a href="../functions/j1.html"><i>j1</i>()</a>, <a href=
"../functions/jn.html"><i>jn</i>()</a>, <a href="../functions/scalb.html"><i>scalb</i>()</a>, <a href=
"../functions/y0.html"><i>y0</i>()</a>, <a href="../functions/y1.html"><i>y1</i>()</a>, <a href=
"../functions/yn.html"><i>yn</i>()</a></dd>
<dt>XSI_MULTI_PROCESS: XSI Multiple Process</dt>
<dd>
<a href="../functions/getpgid.html"><i>getpgid</i>()</a>, <a href="../functions/getpriority.html"><i>getpriority</i>()</a>, <a
href="../functions/getrlimit.html"><i>getrlimit</i>()</a>, <a href="../functions/getrusage.html"><i>getrusage</i>()</a>, <a href=
"../functions/getsid.html"><i>getsid</i>()</a>, <a href="../functions/nice.html"><i>nice</i>()</a>, <a href=
"../functions/setpgrp.html"><i>setpgrp</i>()</a>, <a href="../functions/setpriority.html"><i>setpriority</i>()</a>, <a href=
"../functions/setrlimit.html"><i>setrlimit</i>()</a>, <a href="../functions/ulimit.html"><i>ulimit</i>()</a>, <a href=
"../functions/usleep.html"><i>usleep</i>()</a>, <a href="../functions/vfork.html"><i>vfork</i>()</a>, <a href=
"../functions/waitid.html"><i>waitid</i>()</a></dd>
<dt>XSI_SIGNALS: XSI Signal</dt>
<dd>
<a href="../functions/bsd_signal.html"><i>bsd_signal</i>()</a>, <a href="../functions/killpg.html"><i>killpg</i>()</a>, <a href=
"../functions/sigaltstack.html"><i>sigaltstack</i>()</a>, <a href="../functions/sighold.html"><i>sighold</i>()</a>, <a href=
"../functions/sigignore.html"><i>sigignore</i>()</a>, <a href="../functions/siginterrupt.html"><i>siginterrupt</i>()</a>, <a href=
"../functions/sigpause.html"><i>sigpause</i>()</a>, <a href="../functions/sigrelse.html"><i>sigrelse</i>()</a>, <a href=
"../functions/sigset.html"><i>sigset</i>()</a>, <a href="../functions/ualarm.html"><i>ualarm</i>()</a></dd>
<dt>XSI_SINGLE_PROCESS: XSI Single Process</dt>
<dd>
<a href="../functions/gethostid.html"><i>gethostid</i>()</a>, <a href="../functions/gettimeofday.html"><i>gettimeofday</i>()</a>,
<a href="../functions/putenv.html"><i>putenv</i>()</a></dd>
<dt>XSI_SYSTEM_DATABASE: XSI System Database</dt>
<dd>
<a href="../functions/endpwent.html"><i>endpwent</i>()</a>, <a href="../functions/getpwent.html"><i>getpwent</i>()</a>, <a href=
"../functions/setpwent.html"><i>setpwent</i>()</a></dd>
<dt>XSI_SYSTEM_LOGGING: XSI System Logging</dt>
<dd>
<a href="../functions/closelog.html"><i>closelog</i>()</a>, <a href="../functions/openlog.html"><i>openlog</i>()</a>, <a href=
"../functions/setlogmask.html"><i>setlogmask</i>()</a>, <a href="../functions/syslog.html"><i>syslog</i>()</a></dd>
<dt>XSI_THREAD_MUTEX_EXT: XSI Thread Mutex Extensions</dt>
<dd>
<a href="../functions/pthread_mutexattr_gettype.html"><i>pthread_mutexattr_gettype</i>()</a>, <a href=
"../functions/pthread_mutexattr_settype.html"><i>pthread_mutexattr_settype</i>()</a></dd>
<dt>XSI_THREADS_EXT: XSI Threads Extensions</dt>
<dd>
<a href="../functions/pthread_attr_getguardsize.html"><i>pthread_attr_getguardsize</i>()</a>, <a href=
"../functions/pthread_attr_getstack.html"><i>pthread_attr_getstack</i>()</a>, <a href=
"../functions/pthread_attr_setguardsize.html"><i>pthread_attr_setguardsize</i>()</a>, <a href=
"../functions/pthread_attr_setstack.html"><i>pthread_attr_setstack</i>()</a>, <a href=
"../functions/pthread_getconcurrency.html"><i>pthread_getconcurrency</i>()</a>, <a href=
"../functions/pthread_setconcurrency.html"><i>pthread_setconcurrency</i>()</a></dd>
<dt>XSI_TIMERS: XSI Timers</dt>
<dd>
<a href="../functions/getitimer.html"><i>getitimer</i>()</a>, <a href="../functions/setitimer.html"><i>setitimer</i>()</a></dd>
<dt>XSI_USER_GROUPS: XSI User and Group</dt>
<dd>
<a href="../functions/endgrent.html"><i>endgrent</i>()</a>, <a href="../functions/endutxent.html"><i>endutxent</i>()</a>, <a href=
"../functions/getgrent.html"><i>getgrent</i>()</a>, <a href="../functions/getutxent.html"><i>getutxent</i>()</a>, <a href=
"../functions/getutxid.html"><i>getutxid</i>()</a>, <a href="../functions/getutxline.html"><i>getutxline</i>()</a>, <a href=
"../functions/pututxline.html"><i>pututxline</i>()</a>, <a href="../functions/setgrent.html"><i>setgrent</i>()</a>, <a href=
"../functions/setregid.html"><i>setregid</i>()</a>, <a href="../functions/setreuid.html"><i>setreuid</i>()</a>, <a href=
"../functions/setutxent.html"><i>setutxent</i>()</a></dd>
<dt>XSI_WIDE_CHAR: XSI Wide-Character Library</dt>
<dd>
<a href="../functions/wcswidth.html"><i>wcswidth</i>()</a>, <a href="../functions/wcwidth.html"><i>wcwidth</i>()</a></dd>
</dl>
<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>
<hr>
<h4><a name="tag_05_01_01"></a>Footnotes</h4>
<dl compact>
<dt><a name="tag_foot_1">1.</a></dt>
<dd>These are equivalent to the Units of Functionality from IEEE&nbsp;Std&nbsp;1003.13-1998.</dd>
</dl>
</body>
</html>

1326
Ref-docs/POSIX/susv3/xrat/toc.html Normal file
View File

File diff suppressed because it is too large Load Diff

432
Ref-docs/POSIX/susv3/xrat/xbd_chap01.html Normal file
View File

@@ -0,0 +1,432 @@
<!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 &copy; 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&nbsp;Std&nbsp;1003.1-2001 is one of a family of standards known as POSIX. The family of standards extends to many topics;
IEEE&nbsp;Std&nbsp;1003.1-2001 is known as POSIX.1 and consists of both operating system interfaces and shell and utilities.
IEEE&nbsp;Std&nbsp;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&nbsp;Std&nbsp;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
&quot;adopted&quot; into earlier revisions of POSIX.1 and POSIX.2 are now included in IEEE&nbsp;Std&nbsp;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&nbsp;Std&nbsp;1003.1d-1999</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.1j-2000</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.1q-2000</p>
</li>
<li>
<p>IEEE&nbsp;P1003.1a draft standard</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.2d-1994</p>
</li>
<li>
<p>IEEE&nbsp;P1003.2b draft standard</p>
</li>
<li>
<p>Selected parts of IEEE&nbsp;Std&nbsp;1003.1g-2000</p>
</li>
</ul>
<p>Only selected parts of IEEE&nbsp;Std&nbsp;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&nbsp;Std&nbsp;1003.1g-2000, the former document
being aligned with the latest networking specifications for IPv6. Only the following sections of IEEE&nbsp;Std&nbsp;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>&lt;sys/select.h&gt;</i></a> header (Section 6.2)</p>
</li>
</ul>
<p>The following were requirements on IEEE&nbsp;Std&nbsp;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&nbsp;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&nbsp;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&nbsp;C standard and
the Single UNIX Specification.</p>
<p>It was agreed that where an interface has a version in the ISO&nbsp;C standard, the DESCRIPTION section should describe the
relationship to the ISO&nbsp;C standard and markings should be added as appropriate to show where the ISO&nbsp;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&nbsp;C
standard or extended. Each page was parsed for additions beyond the ISO&nbsp;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&nbsp;Std&nbsp;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&nbsp;Std&nbsp;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>&lt;termios.h&gt;</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&nbsp;Std&nbsp;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&nbsp;Std&nbsp;1003.1-2001, the words <i>shall</i>, <i>should</i>, and <i>may</i>
are sometimes used to illustrate similar usages in IEEE&nbsp;Std&nbsp;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&nbsp;Std&nbsp;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&nbsp;C standard and, together with &quot;undefined&quot; and &quot;unspecified&quot;, 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&nbsp;Std&nbsp;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&nbsp;Std&nbsp;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 &quot;obsolescent&quot; means &quot;do not use this feature in new applications&quot;. 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 &quot;may be considered for
withdrawal in future revisions&quot; 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 &quot;legacy&quot; was added for compatibility with the Single UNIX Specification. It means &quot;this feature is historic and
optional; do not use this feature in new applications. There are alternative interfaces that are more suitable.&quot;. 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 &quot;sunset&quot; 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 &quot;legacy&quot; and &quot;obsolescent&quot; 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&nbsp;Std&nbsp;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 &quot;unspecified&quot; and &quot;undefined&quot; appear nearly identical at first examination, but are not. The term
&quot;unspecified&quot; means that a conforming application may deal with the unspecified behavior, and it should not care what the outcome
is. The term &quot;undefined&quot; 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 &quot;undefined&quot; and &quot;unspecified&quot; apply to the way the application should think about the feature. In terms of
the implementation, it is always &quot;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&nbsp;Std&nbsp;1003.1-2001 specifically.</p>
<p>The term &quot;implementation-defined&quot; implies requirements for documentation that are not required for &quot;undefined&quot; (or
&quot;unspecified&quot;). Where there is no need for a conforming program to know the definition, the term &quot;undefined&quot; is used, even
though &quot;implementation-defined&quot; could also have been used in this context. There could be a fourth term, specifying &quot;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&quot;,
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 &quot;implementation-defined&quot;.</p>
<p>In many places IEEE&nbsp;Std&nbsp;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 &quot;unspecified&quot;.</p>
<p>The term &quot;application&quot; is not defined in IEEE&nbsp;Std&nbsp;1003.1-2001; it is assumed to be a part of general computer
science terminology.</p>
<p>Three terms used within IEEE&nbsp;Std&nbsp;1003.1-2001 overlap in meaning: &quot;macro&quot;, &quot;symbolic name&quot;, and &quot;symbolic
constant&quot;.</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&nbsp;Std&nbsp;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&nbsp;Std&nbsp;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&nbsp;C standard. For interfaces that are duplicated between
IEEE&nbsp;Std&nbsp;1003.1-2001 and the ISO&nbsp;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&nbsp;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&nbsp;C standard header.</p>
</dd>
<dt>MX</dt>
<dd>This margin code is used to denote IEC&nbsp;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 &lt;space&gt; 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 &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>

348
Ref-docs/POSIX/susv3/xrat/xbd_chap02.html Normal file
View File

@@ -0,0 +1,348 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_02"></a>Conformance</h3>
<p>The terms &quot;profile&quot; and &quot;profiling&quot; are used throughout this section.</p>
<p>A profile of a standard or standards is a codified set of option selections, such that by being conformant to a profile,
particular classes of users are specifically supported.</p>
<p>These conformance definitions are descended from those in the ISO&nbsp;POSIX-1:1996 standard, but with changes for the
following:</p>
<ul>
<li>
<p>The addition of profiling options, allowing larger profiles of options such as the XSI extension used by the Single UNIX
Specification. In effect, it has profiled itself (that is, created a self-profile).</p>
</li>
<li>
<p>The addition of a definition of subprofiling considerations, to allow smaller profiles of options.</p>
</li>
<li>
<p>The addition of a hierarchy of super-options for XSI; these were formerly known as &quot;Feature Groups&quot; in the System Interfaces
and Headers, Issue 5 specification.</p>
</li>
<li>
<p>Options from the ISO&nbsp;POSIX-2:1993 standard are also now included, as IEEE&nbsp;Std&nbsp;1003.1-2001 merges the
functionality from it.</p>
</li>
</ul>
<h4><a name="tag_01_02_01"></a>Implementation Conformance</h4>
<p>These definitions allow application developers to know what to depend on in an implementation.</p>
<p>There is no definition of a &quot;strictly conforming implementation''; that would be an implementation that provides <i>only</i>
those facilities specified by POSIX.1 with no extensions whatsoever. This is because no actual operating system implementation can
exist without system administration and initialization facilities that are beyond the scope of POSIX.1.</p>
<h5><a name="tag_01_02_01_01"></a>Requirements</h5>
<p>The word &quot;support&quot; is used in certain instances, rather than &quot;provide&quot;, in order to allow an implementation that has no
resident software development facilities, but that supports the execution of a <i>Strictly Conforming POSIX.1 Application</i>, to
be a <i>conforming implementation</i>.</p>
<h5><a name="tag_01_02_01_02"></a>Documentation</h5>
<p>The conformance documentation is required to use the same numbering scheme as POSIX.1 for purposes of cross-referencing. All
options that an implementation chooses are reflected in <a href="../basedefs/limits.h.html"><i>&lt;limits.h&gt;</i></a> and <a
href="../basedefs/unistd.h.html"><i>&lt;unistd.h&gt;</i></a>.</p>
<p>Note that the use of &quot;may&quot; in terms of where conformance documents record where implementations may vary, implies that it is
not required to describe those features identified as undefined or unspecified.</p>
<p>Other aspects of systems must be evaluated by purchasers for suitability. Many systems incorporate buffering facilities,
maintaining updated data in volatile storage and transferring such updates to non-volatile storage asynchronously. Various
exception conditions, such as a power failure or a system crash, can cause this data to be lost. The data may be associated with a
file that is still open, with one that has been closed, with a directory, or with any other internal system data structures
associated with permanent storage. This data can be lost, in whole or part, so that only careful inspection of file contents could
determine that an update did not occur.</p>
<p>Also, interrelated file activities, where multiple files and/or directories are updated, or where space is allocated or released
in the file system structures, can leave inconsistencies in the relationship between data in the various files and directories, or
in the file system itself. Such inconsistencies can break applications that expect updates to occur in a specific sequence, so that
updates in one place correspond with related updates in another place.</p>
<p>For example, if a user creates a file, places information in the file, and then records this action in another file, a system or
power failure at this point followed by restart may result in a state in which the record of the action is permanently recorded,
but the file created (or some of its information) has been lost. The consequences of this to the user may be undesirable. For a
user on such a system, the only safe action may be to require the system administrator to have a policy that requires, after any
system or power failure, that the entire file system must be restored from the most recent backup copy (causing all intervening
work to be lost).</p>
<p>The characteristics of each implementation will vary in this respect and may or may not meet the requirements of a given
application or user. Enforcement of such requirements is beyond the scope of POSIX.1. It is up to the purchaser to determine what
facilities are provided in an implementation that affect the exposure to possible data or sequence loss, and also what underlying
implementation techniques and/or facilities are provided that reduce or limit such loss or its consequences.</p>
<h5><a name="tag_01_02_01_03"></a>POSIX Conformance</h5>
<p>This really means conformance to the base standard; however, since this revision includes the core material of the Single UNIX
Specification, the standard developers decided that it was appropriate to segment the conformance requirements into two, the former
for the base standard, and the latter for the Single UNIX Specification.</p>
<p>Within POSIX.1 there are some symbolic constants that, if defined, indicate that a certain option is enabled. Other symbolic
constants exist in POSIX.1 for other reasons.</p>
<p>As part of the revision some alignment has occurred of the options with the FIPS 151-2 profile on the POSIX.1-1990 standard. The
following options from the POSIX.1-1990 standard are now mandatory:</p>
<ul>
<li>
<p>_POSIX_JOB_CONTROL</p>
</li>
<li>
<p>_POSIX_SAVED_IDS</p>
</li>
<li>
<p>_POSIX_VDISABLE</p>
</li>
</ul>
<p>A POSIX-conformant system may support the XSI extensions of the Single UNIX Specification. This was intentional since the
standard developers intend them to be upwards-compatible, so that a system conforming to the Single UNIX Specification can also
conform to the base standard at the same time.</p>
<h5><a name="tag_01_02_01_04"></a>XSI Conformance</h5>
<p>This section is added since the revision merges in the base volumes of the Single UNIX Specification.</p>
<p>XSI conformance can be thought of as a profile, selecting certain options from IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<h5><a name="tag_01_02_01_05"></a>Option Groups</h5>
<p>The concept of &quot;Option Groupsc&quot; is introduced to IEEE&nbsp;Std&nbsp;1003.1-2001 to allow collections of related functions or
options to be grouped together. This has been used as follows: the &quot;XSI Option Groups&quot; have been created to allow super-options,
collections of underlying options and related functions, to be collectively supported by XSI-conforming systems. These reflect the
&quot;Feature Groups&quot; from the System Interfaces and Headers, Issue 5 specification.</p>
<p>The standard developers considered the matter of subprofiling and decided it was better to include an enabling mechanism rather
than detailed normative requirements. A set of subprofiling options was developed and included later in this volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 as an informative illustration.</p>
<h5><a name="tag_01_02_01_06"></a>Subprofiling Considerations</h5>
<p>The goal of not simultaneously fixing maximums and minimums was to allow implementations of the base standard or standards to
support multiple profiles without conflict.</p>
<p>The following summarizes the rules for the limit types:</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="center">
<p class="tent"><b>Limit</b></p>
</th>
<th align="center">
<p class="tent"><b>Fixed</b></p>
</th>
<th align="center">
<p class="tent"><b>Minimum Acceptable</b></p>
</th>
<th align="center">
<p class="tent"><b>Maximum Acceptable</b></p>
</th>
</tr>
<tr valign="top">
<th align="center">
<p class="tent"><b>Type</b></p>
</th>
<th align="center">
<p class="tent"><b>Value</b></p>
</th>
<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>

1768
Ref-docs/POSIX/susv3/xrat/xbd_chap03.html Normal file
View File

File diff suppressed because it is too large Load Diff

497
Ref-docs/POSIX/susv3/xrat/xbd_chap04.html Normal file
View File

@@ -0,0 +1,497 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_04"></a>General Concepts</h3>
<h4><a name="tag_01_04_01"></a>Concurrent Execution</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_02"></a>Directory Protection</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_03"></a>Extended Security Controls</h4>
<p>Allowing an implementation to define extended security controls enables the use of IEEE&nbsp;Std&nbsp;1003.1-2001 in
environments that require different or more rigorous security than that provided in POSIX.1. Extensions are allowed in two areas:
privilege and file access permissions. The semantics of these areas have been defined to permit extensions with reasonable, but not
exact, compatibility with all existing practices. For example, the elimination of the superuser definition precludes identifying a
process as privileged or not by virtue of its effective user ID.</p>
<h4><a name="tag_01_04_04"></a>File Access Permissions</h4>
<p>A process should not try to anticipate the result of an attempt to access data by <i>a priori</i> use of these rules. Rather, it
should make the attempt to access data and examine the return value (and possibly <i>errno</i> as well), or use <a href=
"../functions/access.html"><i>access</i>()</a>. An implementation may include other security mechanisms in addition to those
specified in POSIX.1, and an access attempt may fail because of those additional mechanisms, even though it would succeed according
to the rules given in this section. (For example, the user's security level might be lower than that of the object of the access
attempt.) The supplementary group IDs provide another reason for a process to not attempt to anticipate the result of an access
attempt.</p>
<h4><a name="tag_01_04_05"></a>File Hierarchy</h4>
<p>Though the file hierarchy is commonly regarded to be a tree, POSIX.1 does not define it as such for three reasons:</p>
<ol>
<li>
<p>Links may join branches.</p>
</li>
<li>
<p>In some network implementations, there may be no single absolute root directory; see <i>pathname resolution</i>.</p>
</li>
<li>
<p>With symbolic links, the file system need not be a tree or even a directed acyclic graph.</p>
</li>
</ol>
<h4><a name="tag_01_04_06"></a>Filenames</h4>
<p>Historically, certain filenames have been reserved. This list includes <b>core</b>, <b>/etc/passwd</b>, and so on. Conforming
applications should avoid these.</p>
<p>Most historical implementations prohibit case folding in filenames; that is, treating uppercase and lowercase alphabetic
characters as identical. However, some consider case folding desirable:</p>
<ul>
<li>
<p>For user convenience</p>
</li>
<li>
<p>For ease-of-implementation of the POSIX.1 interface as a hosted system on some popular operating systems</p>
</li>
</ul>
<p>Variants, such as maintaining case distinctions in filenames, but ignoring them in comparisons, have been suggested. Methods of
allowing escaped characters of the case opposite the default have been proposed.</p>
<p>Many reasons have been expressed for not allowing case folding, including:</p>
<ul>
<li>
<p>No solid evidence has been produced as to whether case-sensitivity or case-insensitivity is more convenient for users.</p>
</li>
<li>
<p>Making case-insensitivity a POSIX.1 implementation option would be worse than either having it or not having it, because:</p>
<ul>
<li>
<p>More confusion would be caused among users.</p>
</li>
<li>
<p>Application developers would have to account for both cases in their code.</p>
</li>
<li>
<p>POSIX.1 implementors would still have other problems with native file systems, such as short or otherwise constrained filenames
or pathnames, and the lack of hierarchical directory structure.</p>
</li>
</ul>
</li>
<li>
<p>Case folding is not easily defined in many European languages, both because many of them use characters outside the US ASCII
alphabetic set, and because:</p>
<ul>
<li>
<p>In Spanish, the digraph <tt>"ll"</tt> is considered to be a single letter, the capitalized form of which may be either
<tt>"Ll"</tt> or <tt>"LL"</tt> , depending on context.</p>
</li>
<li>
<p>In French, the capitalized form of a letter with an accent may or may not retain the accent, depending on the country in which
it is written.</p>
</li>
<li>
<p>In German, the sharp ess may be represented as a single character resembling a Greek beta (&szlig;) in lowercase, but as the
digraph <tt>"SS"</tt> in uppercase.</p>
</li>
<li>
<p>In Greek, there are several lowercase forms of some letters; the one to use depends on its position in the word. Arabic has
similar rules.</p>
</li>
</ul>
</li>
<li>
<p>Many East Asian languages, including Japanese, Chinese, and Korean, do not distinguish case and are sometimes encoded in
character sets that use more than one byte per character.</p>
</li>
<li>
<p>Multiple character codes may be used on the same machine simultaneously. There are several ISO character sets for European
alphabets. In Japan, several Japanese character codes are commonly used together, sometimes even in filenames; this is evidently
also the case in China. To handle case insensitivity, the kernel would have to at least be able to distinguish for which character
sets the concept made sense.</p>
</li>
<li>
<p>The file system implementation historically deals only with bytes, not with characters, except for slash and the null byte.</p>
</li>
<li>
<p>The purpose of POSIX.1 is to standardize the common, existing definition, not to change it. Mandating case-insensitivity would
make all historical implementations non-standard.</p>
</li>
<li>
<p>Not only the interface, but also application programs would need to change, counter to the purpose of having minimal changes to
existing application code.</p>
</li>
<li>
<p>At least one of the original developers of the UNIX system has expressed objection in the strongest terms to either requiring
case-insensitivity or making it an option, mostly on the basis that POSIX.1 should not hinder portability of application programs
across related implementations in order to allow compatibility with unrelated operating systems.</p>
</li>
</ul>
<p>Two proposals were entertained regarding case folding in filenames:</p>
<ol>
<li>
<p>Remove all wording that previously permitted case folding.</p>
<dl compact>
<dt>Rationale</dt>
<dd>Case folding is inconsistent with portable filename character set definition and filename definition (all characters except
slash and null). No known implementations allowing all characters except slash and null also do case folding.</dd>
</dl>
</li>
<li>
<p>Change &quot;though this practice is not recommended:&quot; to &quot;although this practice is strongly discouraged.&quot;</p>
<dl compact>
<dt>Rationale</dt>
<dd>If case folding must be included in POSIX.1, the wording should be stronger to discourage the practice.</dd>
</dl>
</li>
</ol>
<p>The consensus selected the first proposal. Otherwise, a conforming application would have to assume that case folding would
occur when it was not wanted, but that it would not occur when it was wanted.</p>
<h4><a name="tag_01_04_07"></a>File Times Update</h4>
<p>This section reflects the actions of historical implementations. The times are not updated immediately, but are only marked for
update by the functions. An implementation may update these times immediately.</p>
<p>The accuracy of the time update values is intentionally left unspecified so that systems can control the bandwidth of a possible
covert channel.</p>
<p>The wording was carefully chosen to make it clear that there is no requirement that the conformance document contain information
that might incidentally affect file update times. Any function that performs pathname resolution might update several
<i>st_atime</i> fields. Functions such as <a href="../functions/getpwnam.html"><i>getpwnam</i>()</a> and <a href=
"../functions/getgrnam.html"><i>getgrnam</i>()</a> might update the <i>st_atime</i> field of some specific file or files. It is
intended that these are not required to be documented in the conformance document, but they should appear in the system
documentation.</p>
<h4><a name="tag_01_04_08"></a>Host and Network Byte Order</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_09"></a>Measurement of Execution Time</h4>
<p>The methods used to measure the execution time of processes and threads, and the precision of these measurements, may vary
considerably depending on the software architecture of the implementation, and on the underlying hardware. Implementations can also
make tradeoffs between the scheduling overhead and the precision of the execution time measurements. IEEE&nbsp;Std&nbsp;1003.1-2001
does not impose any requirement on the accuracy of the execution time; it instead specifies that the measurement mechanism and its
precision are implementation-defined.</p>
<h4><a name="tag_01_04_10"></a>Memory Synchronization</h4>
<p>In older multi-processors, access to memory by the processors was strictly multiplexed. This meant that a processor executing
program code interrogates or modifies memory in the order specified by the code and that all the memory operation of all the
processors in the system appear to happen in some global order, though the operation histories of different processors are
interleaved arbitrarily. The memory operations of such machines are said to be sequentially consistent. In this environment,
threads can synchronize using ordinary memory operations. For example, a producer thread and a consumer thread can synchronize
access to a circular data buffer as follows:</p>
<blockquote>
<pre>
<tt>int rdptr = 0;
int wrptr = 0;
data_t buf[BUFSIZE];
<br>
Thread 1:
while (work_to_do) {
int next;
<br>
buf[wrptr] = produce();
next = (wrptr + 1) % BUFSIZE;
while (rdptr == next)
;
wrptr = next;
}
<br>
Thread 2:
while (work_to_do) {
while (rdptr == wrptr)
;
consume(buf[rdptr]);
rdptr = (rdptr + 1) % BUFSIZE;
}
</tt>
</pre>
</blockquote>
<p>In modern multi-processors, these conditions are relaxed to achieve greater performance. If one processor stores values in
location A and then location B, then other processors loading data from location B and then location A may see the new value of B
but the old value of A. The memory operations of such machines are said to be weakly ordered. On these machines, the circular
buffer technique shown in the example will fail because the consumer may see the new value of <i>wrptr</i> but the old value of the
data in the buffer. In such machines, synchronization can only be achieved through the use of special instructions that enforce an
order on memory operations. Most high-level language compilers only generate ordinary memory operations to take advantage of the
increased performance. They usually cannot determine when memory operation order is important and generate the special ordering
instructions. Instead, they rely on the programmer to use synchronization primitives correctly to ensure that modifications to a
location in memory are ordered with respect to modifications and/or access to the same location in other threads. Access to
read-only data need not be synchronized. The resulting program is said to be data race-free.</p>
<p>Synchronization is still important even when accessing a single primitive variable (for example, an integer). On machines where
the integer may not be aligned to the bus data width or be larger than the data width, a single memory load may require multiple
memory cycles. This means that it may be possible for some parts of the integer to have an old value while other parts have a newer
value. On some processor architectures this cannot happen, but portable programs cannot rely on this.</p>
<p>In summary, a portable multi-threaded program, or a multi-process program that shares writable memory between processes, has to
use the synchronization primitives to synchronize data access. It cannot rely on modifications to memory being observed by other
threads in the order written in the application or even on modification of a single variable being seen atomically.</p>
<p>Conforming applications may only use the functions listed to synchronize threads of control with respect to memory access. There
are many other candidates for functions that might also be used. Examples are: signal sending and reception, or pipe writing and
reading. In general, any function that allows one thread of control to wait for an action caused by another thread of control is a
candidate. IEEE&nbsp;Std&nbsp;1003.1-2001 does not require these additional functions to synchronize memory access since this would
imply the following:</p>
<ul>
<li>
<p>All these functions would have to be recognized by advanced compilation systems so that memory operations and calls to these
functions are not reordered by optimization.</p>
</li>
<li>
<p>All these functions would potentially have to have memory synchronization instructions added, depending on the particular
machine.</p>
</li>
<li>
<p>The additional functions complicate the model of how memory is synchronized and make automatic data race detection techniques
impractical.</p>
</li>
</ul>
<p>Formal definitions of the memory model were rejected as unreadable by the vast majority of programmers. In addition, most of the
formal work in the literature has concentrated on the memory as provided by the hardware as opposed to the application programmer
through the compiler and runtime system. It was believed that a simple statement intuitive to most programmers would be most
effective. IEEE&nbsp;Std&nbsp;1003.1-2001 defines functions that can be used to synchronize access to memory, but it leaves open
exactly how one relates those functions to the semantics of each function as specified elsewhere in IEEE&nbsp;Std&nbsp;1003.1-2001.
IEEE&nbsp;Std&nbsp;1003.1-2001 also does not make a formal specification of the partial ordering in time that the functions can
impose, as that is implied in the description of the semantics of each function. It simply states that the programmer has to ensure
that modifications do not occur &quot;simultaneously&quot; with other access to a memory location.</p>
<h4><a name="tag_01_04_11"></a>Pathname Resolution</h4>
<p>It is necessary to differentiate between the definition of pathname and the concept of pathname resolution with respect to the
handling of trailing slashes. By specifying the behavior here, it is not possible to provide an implementation that is conforming
but extends all interfaces that handle pathnames to also handle strings that are not legal pathnames (because they have trailing
slashes).</p>
<p>Pathnames that end with one or more trailing slash characters must refer to directory paths. Previous versions of
IEEE&nbsp;Std&nbsp;1003.1-2001 were not specific about the distinction between trailing slashes on files and directories, and both
were permitted.</p>
<p>Two types of implementation have been prevalent; those that ignored trailing slash characters on all pathnames regardless, and
those that permitted them only on existing directories.</p>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 requires that a pathname with a trailing slash character be treated as if it had a trailing
<tt>"/."</tt> everywhere.</p>
<p>Note that this change does not break any conforming applications; since there were two different types of implementation, no
application could have portably depended on either behavior. This change does however require some implementations to be altered to
remain compliant. Substantial discussion over a three-year period has shown that the benefits to application developers outweighs
the disadvantages for some vendors.</p>
<p>On a historical note, some early applications automatically appended a <tt>'/'</tt> to every path. Rather than fix the
applications, the system implementation was modified to accept this behavior by ignoring any trailing slash.</p>
<p>Each directory has exactly one parent directory which is represented by the name <b>dot-dot</b> in the first directory. No other
directory, regardless of linkages established by symbolic links, is considered the parent directory by
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>There are two general categories of interfaces involving pathname resolution: those that follow the symbolic link, and those
that do not. There are several exceptions to this rule; for example, <i>open</i>( <i>path</i>,O_CREAT|O_EXCL) will fail when
<i>path</i> names a symbolic link. However, in all other situations, the <a href="../functions/open.html"><i>open</i>()</a>
function will follow the link.</p>
<p>What the filename <b>dot-dot</b> refers to relative to the root directory is implementation-defined. In Version&nbsp;7 it refers
to the root directory itself; this is the behavior mentioned in IEEE&nbsp;Std&nbsp;1003.1-2001. In some networked systems the
construction <b>/../hostname/</b> is used to refer to the root directory of another host, and POSIX.1 permits this behavior.</p>
<p>Other networked systems use the construct <b>//hostname</b> for the same purpose; that is, a double initial slash is used. There
is a potential problem with existing applications that create full pathnames by taking a trunk and a relative pathname and making
them into a single string separated by <tt>'/'</tt> , because they can accidentally create networked pathnames when the trunk is
<tt>'/'</tt> . This practice is not prohibited because such applications can be made to conform by simply changing to use
<tt>"//"</tt> as a separator instead of <tt>'/'</tt> :</p>
<ul>
<li>
<p>If the trunk is <tt>'/'</tt> , the full pathname will begin with <tt>"///"</tt> (the initial <tt>'/'</tt> and the separator
<tt>"//"</tt> ). This is the same as <tt>'/'</tt> , which is what is desired. (This is the general case of making a relative
pathname into an absolute one by prefixing with <tt>"///"</tt> instead of <tt>'/'</tt> .)</p>
</li>
<li>
<p>If the trunk is <tt>"/A"</tt> , the result is <tt>"/A//..."</tt> ; since non-leading sequences of two or more slashes are
treated as a single slash, this is equivalent to the desired <tt>"/A/..."</tt> .</p>
</li>
<li>
<p>If the trunk is <tt>"//A"</tt> , the implementation-defined semantics will apply. (The multiple slash rule would apply.)</p>
</li>
</ul>
<p>Application developers should avoid generating pathnames that start with <tt>"//"</tt> . Implementations are strongly encouraged
to avoid using this special interpretation since a number of applications currently do not follow this practice and may
inadvertently generate <tt>"//..."</tt> .</p>
<p>The term &quot;root directory&quot; is only defined in POSIX.1 relative to the process. In some implementations, there may be no
absolute root directory. The initialization of the root directory of a process is implementation-defined.</p>
<h4><a name="tag_01_04_12"></a>Process ID Reuse</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_13"></a>Scheduling Policy</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_14"></a>Seconds Since the Epoch</h4>
<p>Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are
ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore
not necessarily UTC, despite its appearance.</p>
<p>As of September 2000, 24 leap seconds had been added to UTC since the Epoch, 1 January, 1970. Historically, one leap second is
added every 15 months on average, so this offset can be expected to grow steadily with time.</p>
<p>Most systems' notion of &quot;time&quot; is that of a continuously increasing value, so this value should increase even during leap
seconds. However, not only do most systems not keep track of leap seconds, but most systems are probably not synchronized to any
standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely
represent the number of seconds between the referenced time and the Epoch.</p>
<p>It is sufficient to require that applications be allowed to treat this time as if it represented the number of seconds between
the referenced time and the Epoch. It is the responsibility of the vendor of the system, and the administrator of the system, to
ensure that this value represents the number of seconds between the referenced time and the Epoch as closely as necessary for the
application being run on that system.</p>
<p>It is important that the interpretation of time names and seconds since the Epoch values be consistent across conforming
systems; that is, it is important that all conforming systems interpret &quot;536457599 seconds since the Epoch&quot; as 59 seconds, 59
minutes, 23 hours 31 December 1986, regardless of the accuracy of the system's idea of the current time. The expression is given to
ensure a consistent interpretation, not to attempt to specify the calendar. The relationship between <i>tm_yday</i> and the day of
week, day of month, and month is in accordance with the Gregorian calendar, and so is not specified in POSIX.1.</p>
<p>Consistent interpretation of seconds since the Epoch can be critical to certain types of distributed applications that rely on
such timestamps to synchronize events. The accrual of leap seconds in a time standard is not predictable. The number of leap
seconds since the Epoch will likely increase. POSIX.1 is more concerned about the synchronization of time between applications of
astronomically short duration.</p>
<p>Note that <i>tm_yday</i> is zero-based, not one-based, so the day number in the example above is 364. Note also that the
division is an integer division (discarding remainder) as in the C language.</p>
<p>Note also that the meaning of <a href="../functions/gmtime.html"><i>gmtime</i>()</a>, <a href=
"../functions/localtime.html"><i>localtime</i>()</a>, and <a href="../functions/mktime.html"><i>mktime</i>()</a> is specified in
terms of this expression. However, the ISO&nbsp;C standard computes <i>tm_yday</i> from <i>tm_mday</i>, <i>tm_mon</i>, and
<i>tm_year</i> in <a href="../functions/mktime.html"><i>mktime</i>()</a>. Because it is stated as a (bidirectional) relationship,
not a function, and because the conversion between month-day-year and day-of-year dates is presumed well known and is also a
relationship, this is not a problem.</p>
<p>Implementations that implement <b>time_t</b> as a signed 32-bit integer will overflow in 2038. The data size for <b>time_t</b>
is as per the ISO&nbsp;C standard definition, which is implementation-defined.</p>
<p>See also <a href="xbd_chap03.html#tag_01_03_00_15"><i>Epoch</i></a> .</p>
<p>The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each
time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days
identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the
Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap
seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because
there was disagreement about what the best way of handling leap seconds might be. It is a practical impossibility to mandate that a
conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems
performing &quot;reruns&quot; by setting the clock to some arbitrary time).</p>
<p>Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified.
This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a
system that provides the particular handling of external time in the way required by the application.</p>
<h4><a name="tag_01_04_15"></a>Semaphore</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_16"></a>Thread-Safety</h4>
<p>Where the interface of a function required by IEEE&nbsp;Std&nbsp;1003.1-2001 precludes thread-safety, an alternate thread-safe
form is provided. The names of these thread-safe forms are the same as the non-thread-safe forms with the addition of the suffix
&quot;_r&quot;. The suffix &quot;_r&quot; is historical, where the <tt>'r'</tt> stood for &quot;reentrant&quot;.</p>
<p>In some cases, thread-safety is provided by restricting the arguments to an existing function.</p>
<p>See also <a href="xsh_chap02.html#tag_03_02_09_08"><i>Thread-Safety</i></a> .</p>
<h4><a name="tag_01_04_17"></a>Tracing</h4>
<p>Refer to <a href="xsh_chap02.html#tag_03_02_11"><i>Tracing</i></a> .</p>
<h4><a name="tag_01_04_18"></a>Treatment of Error Conditions for Mathematical Functions</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_19"></a>Treatment of NaN Arguments for Mathematical Functions</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_20"></a>Utility</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_04_21"></a>Variable Assignment</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>

82
Ref-docs/POSIX/susv3/xrat/xbd_chap05.html Normal file
View File

@@ -0,0 +1,82 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_05"></a>File Format Notation</h3>
<p>The notation for spaces allows some flexibility for application output. Note that an empty character position in <i>format</i>
represents one or more &lt;blank&gt;s on the output (not <i>white space</i>, which can include &lt;newline&gt;s). Therefore,
another utility that reads that output as its input must be prepared to parse the data using <a href=
"../functions/scanf.html"><i>scanf</i>()</a>, <a href="../utilities/awk.html"><i>awk</i></a>, and so on. The <tt>'<img src=
"../images/delta.gif" border="0">'</tt> character is used when exactly one &lt;space&gt; is output.</p>
<p>The treatment of integers and spaces is different from the <a href="../functions/printf.html"><i>printf</i>()</a> function in
that they can be surrounded with &lt;blank&gt;s. This was done so that, given a format such as:</p>
<blockquote>
<pre>
<tt>"%d\n",&lt;</tt><i>foo</i><tt>&gt;
</tt>
</pre>
</blockquote>
<p>the implementation could use a <a href="../functions/printf.html"><i>printf</i>()</a> call such as:</p>
<blockquote>
<pre>
<tt>printf("%6d\n", foo);
</tt>
</pre>
</blockquote>
<p>and still conform. This notation is thus somewhat like <a href="../functions/scanf.html"><i>scanf</i>()</a> in addition to <a
href="../functions/printf.html"><i>printf</i>()</a>.</p>
<p>The <a href="../functions/printf.html"><i>printf</i>()</a> function was chosen as a model because most of the standard
developers were familiar with it. One difference from the C function <a href="../functions/printf.html"><i>printf</i>()</a> is that
the <tt>l</tt> and <tt>h</tt> conversion specifier characters are not used. As expressed by the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, there is no differentiation between decimal values for type <b>int</b>, type <b>long</b>, or type
<b>short</b>. The conversion specifications <tt>%d</tt> or <tt>%i</tt> should be interpreted as an arbitrary length sequence of
digits. Also, no distinction is made between single precision and double precision numbers ( <b>float</b> or <b>double</b> in C).
These are simply referred to as floating-point numbers.</p>
<p>Many of the output descriptions in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 use the term ``line'', such
as:</p>
<blockquote>
<pre>
<tt>"%s", &lt;input line&gt;
</tt>
</pre>
</blockquote>
<p>Since the definition of <i>line</i> includes the trailing &lt;newline&gt; already, there is no need to include a <tt>'\n'</tt>
in the format; a double &lt;newline&gt; would otherwise result.</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>

214
Ref-docs/POSIX/susv3/xrat/xbd_chap06.html Normal file
View File

@@ -0,0 +1,214 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_06"></a>Character Set</h3>
<h4><a name="tag_01_06_01"></a>Portable Character Set</h4>
<p>The portable character set is listed in full so there is no dependency on the ISO/IEC&nbsp;646:1991 standard (or historically
ASCII) encoded character set, although the set is identical to the characters defined in the International Reference version of the
ISO/IEC&nbsp;646:1991 standard.</p>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 poses no requirement that multiple character sets or codesets be supported, leaving this as a
marketing differentiation for implementors. Although multiple charmap files are supported, it is the responsibility of the
implementation to provide the file(s); if only one is provided, only that one will be accessible using the <a href=
"../utilities/localedef.html"><i>localedef</i></a> <b>-f</b> option.</p>
<p>The statement about invariance in codesets for the portable character set is worded to avoid precluding implementations where
multiple incompatible codesets are available (for instance, ASCII and EBCDIC). The standard utilities cannot be expected to produce
predictable results if they access portable characters that vary on the same implementation.</p>
<p>Not all character sets need include the portable character set, but each locale must include it. For example, a Japanese-based
locale might be supported by a mixture of character sets: JIS&nbsp;X&nbsp;0201 Roman (a Japanese version of the
ISO/IEC&nbsp;646:1991 standard), JIS&nbsp;X&nbsp;0208, and JIS&nbsp;X&nbsp;0201 Katakana. Not all of these character sets include
the portable characters, but at least one does (JIS&nbsp;X&nbsp;0201 Roman).</p>
<h4><a name="tag_01_06_02"></a>Character Encoding</h4>
<p>Encoding mechanisms based on single shifts, such as the EUC encoding used in some Asian and other countries, can be supported
via the current charmap mechanism. With single-shift encoding, each character is preceded by a shift code (SS2 or SS3). A complete
EUC code, consisting of the portable character set (G0) and up to three additional character sets (G1, G2, G3), can be described
using the current charmap mechanism; the encoding for each character in additional character sets G2 and G3 must then include their
single-shift code. Other mechanisms to support locales based on encoding mechanisms such as locking shift are not addressed by this
volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<h4><a name="tag_01_06_03"></a>C Language Wide-Character Codes</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_06_04"></a>Character Set Description File</h4>
<p>IEEE PASC Interpretation 1003.2 #196 is applied, removing three lines of text dealing with ranges of symbolic names using
position constant values which had been erroneously included in the final IEEE&nbsp;P1003.2b draft standard.</p>
<h5><a name="tag_01_06_04_01"></a>State-Dependent Character Encodings</h5>
<p>A requirement was considered that would force utilities to eliminate any redundant locking shifts, but this was left as a
quality of implementation issue.</p>
<p>This change satisfies the following requirement from the ISO&nbsp;POSIX-2:1993 standard, Annex H.1:</p>
<blockquote><i>The support of state-dependent (shift encoding) character sets should be addressed fully. See descriptions of these
in the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, Section 6.2, Character Encoding. If such character encodings are
supported, it is expected that this will impact the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, Section 6.2,
Character Encoding, the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap07.html">Chapter 7,
Locale</a>, the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap09.html">Chapter 9, Regular
Expressions</a> , and the <a href="../utilities/comm.html"><i>comm</i></a>, <a href="../utilities/cut.html"><i>cut</i></a>, <a
href="../utilities/diff.html"><i>diff</i></a>, <a href="../utilities/grep.html"><i>grep</i></a>, <a href=
"../utilities/head.html"><i>head</i></a>, <a href="../utilities/join.html"><i>join</i></a>, <a href=
"../utilities/paste.html"><i>paste</i></a>, and <a href="../utilities/tail.html"><i>tail</i></a> utilities.</i></blockquote>
<p>The character set description file provides:</p>
<ul>
<li>
<p>The capability to describe character set attributes (such as collation order or character classes) independent of character set
encoding, and using only the characters in the portable character set. This makes it possible to create generic <a href=
"../utilities/localedef.html"><i>localedef</i></a> source files for all codesets that share the portable character set (such as the
ISO&nbsp;8859 family or IBM Extended ASCII).</p>
</li>
<li>
<p>Standardized symbolic names for all characters in the portable character set, making it possible to refer to any such character
regardless of encoding.</p>
</li>
</ul>
<p>Implementations are free to choose their own symbolic names, as long as the names identified by the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 are also defined; this provides support for already existing &quot;character names&quot;.</p>
<p>The names selected for the members of the portable character set follow the ISO/IEC&nbsp;8859-1:1998 standard and the
ISO/IEC&nbsp;10646-1:2000 standard. However, several commonly used UNIX system names occur as synonyms in the list:</p>
<ul>
<li>
<p>The historical UNIX system names are used for control characters.</p>
</li>
<li>
<p>The word &quot;slash&quot; is given in addition to &quot;solidus&quot;.</p>
</li>
<li>
<p>The word &quot;backslash&quot; is given in addition to &quot;reverse-solidus&quot;.</p>
</li>
<li>
<p>The word &quot;hyphen&quot; is given in addition to &quot;hyphen-minus&quot;.</p>
</li>
<li>
<p>The word &quot;period&quot; is given in addition to &quot;full-stop&quot;.</p>
</li>
<li>
<p>For digits, the word &quot;digit&quot; is eliminated.</p>
</li>
<li>
<p>For letters, the words &quot;Latin Capital Letter&quot; and &quot;Latin Small Letter&quot; are eliminated.</p>
</li>
<li>
<p>The words &quot;left brace&quot; and &quot;right brace&quot; are given in addition to &quot;left-curly-bracket&quot; and &quot;right-curly-bracket&quot;.</p>
</li>
<li>
<p>The names of the digits are preferred over the numbers to avoid possible confusion between <tt>'0'</tt> and <tt>'O'</tt> , and
between <tt>'1'</tt> and <tt>'l'</tt> (one and the letter ell).</p>
</li>
</ul>
<p>The names for the control characters in the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/xbd_chap06.html">Chapter 6, Character Set</a> were taken from the ISO/IEC&nbsp;4873:1991 standard.</p>
<p>The charmap file was introduced to resolve problems with the portability of, especially, <a href=
"../utilities/localedef.html"><i>localedef</i></a> sources. IEEE&nbsp;Std&nbsp;1003.1-2001 assumes that the portable character set
is constant across all locales, but does not prohibit implementations from supporting two incompatible codings, such as both ASCII
and EBCDIC. Such dual-support implementations should have all charmaps and <a href=
"../utilities/localedef.html"><i>localedef</i></a> sources encoded using one portable character set, in effect cross-compiling for
the other environment. Naturally, charmaps (and <a href="../utilities/localedef.html"><i>localedef</i></a> sources) are only
portable without transformation between systems using the same encodings for the portable character set. They can, however, be
transformed between two sets using only a subset of the actual characters (the portable character set). However, the particular
coded character set used for an application or an implementation does not necessarily imply different characteristics or collation;
on the contrary, these attributes should in many cases be identical, regardless of codeset. The charmap provides the capability to
define a common locale definition for multiple codesets (the same <a href="../utilities/localedef.html"><i>localedef</i></a> source
can be used for codesets with different extended characters; the ability in the charmap to define empty names allows for characters
missing in certain codesets).</p>
<p>The <b>&lt;escape_char&gt;</b> declaration was added at the request of the international community to ease the creation of
portable charmap files on terminals not implementing the default backslash escape. The <b>&lt;comment_char&gt;</b> declaration was
added at the request of the international community to eliminate the potential confusion between the number sign and the pound
sign.</p>
<p>The octal number notation with no leading zero required was selected to match those of <a href=
"../utilities/awk.html"><i>awk</i></a> and <a href="../utilities/tr.html"><i>tr</i></a> and is consistent with that used by <a
href="../utilities/localedef.html"><i>localedef</i></a>. To avoid confusion between an octal constant and the back-references used
in <a href="../utilities/localedef.html"><i>localedef</i></a> source, the octal, hexadecimal, and decimal constants must contain at
least two digits. As single-digit constants are relatively rare, this should not impose any significant hardship. Provision is made
for more digits to account for systems in which the byte size is larger than 8 bits. For example, a Unicode
(ISO/IEC&nbsp;10646-1:2000 standard) system that has defined 16-bit bytes may require six octal, four hexadecimal, and five decimal
digits.</p>
<p>The decimal notation is supported because some newer international standards define character values in decimal, rather than in
the old column/row notation.</p>
<p>The charmap identifies the coded character sets supported by an implementation. At least one charmap must be provided, but no
implementation is required to provide more than one. Likewise, implementations can allow users to generate new charmaps (for
instance, for a new version of the ISO&nbsp;8859 family of coded character sets), but does not have to do so. If users are allowed
to create new charmaps, the system documentation describes the rules that apply (for instance, &quot;only coded character sets that are
supersets of the ISO/IEC&nbsp;646:1991 standard IRV, no multi-byte characters&quot;).</p>
<p>This addition of the <b>WIDTH</b> specification satisfies the following requirement from the ISO&nbsp;POSIX-2:1993 standard,
Annex H.1:</p>
<blockquote>
<dl compact>
<dt>(9)</dt>
<dd><i>The definition of column position relies on the implementation's knowledge of the integral width of the characters. The
charmap or</i> LC_CTYPE locale definitions should be enhanced to allow application specification of these widths.</dd>
</dl>
</blockquote>
<p>The character &quot;width&quot; information was first considered for inclusion under <i>LC_CTYPE</i> but was moved because it is more
closely associated with the information in the charmap than information in the locale source (cultural conventions information).
Concerns were raised that formalizing this type of information is moving the locale source definition from the codeset-independent
entity that it was designed to be to a repository of codeset-specific information. A similar issue occurred with the
<b>&lt;code_set_name&gt;</b>, <b>&lt;mb_cur_max&gt;</b>, and <b>&lt;mb_cur_min&gt;</b> information, which was resolved to reside in
the charmap definition.</p>
<p>The width definition was added to the IEEE&nbsp;P1003.2b draft standard with the intent that the <a href=
"../functions/wcswidth.html"><i>wcswidth</i>()</a> and/or <a href="../functions/wcwidth.html"><i>wcwidth</i>()</a> functions
(currently specified in the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001) be the mechanism to retrieve the character
width information.</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>

901
Ref-docs/POSIX/susv3/xrat/xbd_chap07.html Normal file
View File

@@ -0,0 +1,901 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_07"></a>Locale</h3>
<h4><a name="tag_01_07_01"></a>General</h4>
<p>The description of locales is based on work performed in the UniForum Technical Committee, Subcommittee on Internationalization.
Wherever appropriate, keywords are taken from the ISO&nbsp;C standard or the X/Open Portability Guide.</p>
<p>The value used to specify a locale with environment variables is the name specified as the <i>name</i> operand to the <a href=
"../utilities/localedef.html"><i>localedef</i></a> utility when the locale was created. This provides a verifiable method to create
and invoke a locale.</p>
<p>The &quot;object&quot; definitions need not be portable, as long as &quot;source&quot; definitions are. Strictly speaking, source definitions
are portable only between implementations using the same character set(s). Such source definitions, if they use symbolic names
only, easily can be ported between systems using different codesets, as long as the characters in the portable character set (see
the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap06.html#tag_06_01">Section 6.1,
Portable Character Set</a>) have common values between the codesets; this is frequently the case in historical implementations. Of
source, this requires that the symbolic names used for characters outside the portable character set be identical between character
sets. The definition of symbolic names for characters is outside the scope of IEEE&nbsp;Std&nbsp;1003.1-2001, but is certainly
within the scope of other standards organizations.</p>
<p>Applications can select the desired locale by invoking the <a href="../functions/setlocale.html"><i>setlocale</i>()</a> function
(or equivalent) with the appropriate value. If the function is invoked with an empty string, the value of the corresponding
environment variable is used. If the environment variable is not set or is set to the empty string, the implementation sets the
appropriate environment as defined in the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/xbd_chap08.html">Chapter 8, Environment Variables</a>.</p>
<h4><a name="tag_01_07_02"></a>POSIX Locale</h4>
<p>The POSIX locale is equal to the C locale. To avoid being classified as a C-language function, the name has been changed to the
POSIX locale; the environment variable value can be either <tt>"POSIX"</tt> or, for historical reasons, <tt>"C"</tt> .</p>
<p>The POSIX definitions mirror the historical UNIX system behavior.</p>
<p>The use of symbolic names for characters in the tables does not imply that the POSIX locale must be described using symbolic
character names, but merely that it may be advantageous to do so.</p>
<h4><a name="tag_01_07_03"></a>Locale Definition</h4>
<p>The decision to separate the file format from the <a href="../utilities/localedef.html"><i>localedef</i></a> utility description
was only partially editorial. Implementations may provide other interfaces than <a href=
"../utilities/localedef.html"><i>localedef</i></a>. Requirements on &quot;the utility&quot;, mostly concerning error messages, are
described in this way because they are meant to affect the other interfaces implementations may provide as well as <a href=
"../utilities/localedef.html"><i>localedef</i></a>.</p>
<p>The text about POSIX2_LOCALEDEF does not mean that internationalization is optional; only that the functionality of the <a href=
"../utilities/localedef.html"><i>localedef</i></a> utility is. REs, for instance, must still be able to recognize, for example,
character class expressions such as <tt>"[[:alpha:]]"</tt> . A possible analogy is with an applications development environment;
while all conforming implementations must be capable of executing applications, not all need to have the development environment
installed. The assumption is that the capability to modify the behavior of utilities (and applications) via locale settings must be
supported. If the <a href="../utilities/localedef.html"><i>localedef</i></a> utility is not present, then the only choice is to
select an existing (presumably implementation-documented) locale. An implementation could, for example, choose to support only the
POSIX locale, which would in effect limit the amount of changes from historical implementations quite drastically. The <a href=
"../utilities/localedef.html"><i>localedef</i></a> utility is still required, but would always terminate with an exit code
indicating that no locale could be created. Supported locales must be documented using the syntax defined in this chapter. (This
ensures that users can accurately determine what capabilities are provided. If the implementation decides to provide additional
capabilities to the ones in this chapter, that is already provided for.)</p>
<p>If the option is present (that is, locales can be created), then the <a href="../utilities/localedef.html"><i>localedef</i></a>
utility must be capable of creating locales based on the syntax and rules defined in this chapter. This does not mean that the
implementation cannot also provide alternate means for creating locales.</p>
<p>The octal, decimal, and hexadecimal notations are the same employed by the charmap facility (see the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap06.html#tag_06_04">Section 6.4, Character Set Description File</a>).
To avoid confusion between an octal constant and a back-reference, the octal, hexadecimal, and decimal constants must contain at
least two digits. As single-digit constants are relatively rare, this should not impose any significant hardship. Provision is made
for more digits to account for systems in which the byte size is larger than 8 bits. For example, a Unicode (see the
ISO/IEC&nbsp;10646-1:2000 standard) system that has defined 16-bit bytes may require six octal, four hexadecimal, and five decimal
digits. As with the charmap file, multi-byte characters are described in the locale definition file using &quot;big-endian&quot; notation
for reasons of portability. There is no requirement that the internal representation in the computer memory be in this same
order.</p>
<p>One of the guidelines used for the development of this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is that characters outside the
invariant part of the ISO/IEC&nbsp;646:1991 standard should not be used in portable specifications. The backslash character is not
in the invariant part; the number sign is, but with multiple representations: as a number sign, and as a pound sign. As far as
general usage of these symbols, they are covered by the &quot;grandfather clause&quot;, but for newly defined interfaces, the WG15 POSIX
working group has requested that POSIX provide alternate representations. Consequently, while the default escape character remains
the backslash and the default comment character is the number sign, implementations are required to recognize alternative
representations, identified in the applicable source file via the <b>&lt;escape_char&gt;</b> and <b>&lt;comment_char&gt;</b>
keywords.</p>
<h5><a name="tag_01_07_03_01"></a>LC_CTYPE</h5>
<p>The <i>LC_CTYPE</i> category is primarily used to define the encoding-independent aspects of a character set, such as character
classification. In addition, certain encoding-dependent characteristics are also defined for an application via the <i>LC_CTYPE</i>
category. IEEE&nbsp;Std&nbsp;1003.1-2001 does not mandate that the encoding used in the locale is the same as the one used by the
application because an implementation may decide that it is advantageous to define locales in a system-wide encoding rather than
having multiple, logically identical locales in different encodings, and to convert from the application encoding to the
system-wide encoding on usage. Other implementations could require encoding-dependent locales.</p>
<p>In either case, the <i>LC_CTYPE</i> attributes that are directly dependent on the encoding, such as <b>&lt;mb_cur_max&gt;</b>
and the display width of characters, are not user-specifiable in a locale source and are consequently not defined as keywords.</p>
<p>Implementations may define additional keywords or extend the <i>LC_CTYPE</i> mechanism to allow application-defined
keywords.</p>
<p>The text &quot;The ellipsis specification shall only be valid within a single encoded character set&quot; is present because it is
possible to have a locale supported by multiple character encodings, as explained in the rationale for the Base Definitions volume
of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap06.html#tag_06_01">Section 6.1, Portable Character Set</a>. An
example given there is of a possible Japanese-based locale supported by a mixture of the character sets JIS&nbsp;X&nbsp;0201 Roman,
JIS&nbsp;X&nbsp;0208, and JIS&nbsp;X&nbsp;0201 Katakana. Attempting to express a range of characters across these sets is not
logical and the implementation is free to reject such attempts.</p>
<p>As the <i>LC_CTYPE</i> character classes are based on the ISO&nbsp;C standard character class definition, the category does not
support multi-character elements. For instance, the German character &lt;sharp-s&gt; is traditionally classified as a lowercase
letter. There is no corresponding uppercase letter; in proper capitalization of German text, the &lt;sharp-s&gt; will be replaced
by <tt>"SS"</tt> ; that is, by two characters. This kind of conversion is outside the scope of the <b>toupper</b> and
<b>tolower</b> keywords.</p>
<p>Where IEEE&nbsp;Std&nbsp;1003.1-2001 specifies that only certain characters can be specified, as for the keywords <b>digit</b>
and <b>xdigit</b>, the specified characters must be from the portable character set, as shown. As an example, only the Arabic
digits 0 through 9 are acceptable as digits.</p>
<p>The character classes <b>digit</b>, <b>xdigit</b>, <b>lower</b>, <b>upper</b>, and <b>space</b> have a set of automatically
included characters. These only need to be specified if the character values (that is, encoding) differs from the implementation
default values. It is not possible to define a locale without these automatically included characters unless some implementation
extension is used to prevent their inclusion. Such a definition would not be a proper superset of the C locale, and thus, it might
not be possible for the standard utilities to be implemented as programs conforming to the ISO&nbsp;C standard.</p>
<p>The definition of character class <b>digit</b> requires that only ten characters-the ones defining digits-can be specified;
alternate digits (for example, Hindi or Kanji) cannot be specified here. However, the encoding may vary if an implementation
supports more than one encoding.</p>
<p>The definition of character class <b>xdigit</b> requires that the characters included in character class <b>digit</b> are
included here also and allows for different symbols for the hexadecimal digits 10 through 15.</p>
<p>The inclusion of the <b>charclass</b> keyword satisfies the following requirement from the ISO&nbsp;POSIX-2:1993 standard, Annex
H.1:</p>
<dl compact>
<dt>(3)</dt>
<dd><i>The</i> LC_CTYPE (2.5.2.1) locale definition should be enhanced to allow user-specified additional character classes,
similar in concept to the ISO&nbsp;C standard Multibyte Support Extension (MSE) <a href=
"../functions/iswctype.html"><i>iswctype</i>()</a> function.</dd>
</dl>
<p>This keyword was previously included in The Open Group specifications and is now mandated in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>The symbolic constant {CHARCLASS_NAME_MAX} was also adopted from The Open Group specifications. Applications portability is
enhanced by the use of symbolic constants.</p>
<h5><a name="tag_01_07_03_02"></a>LC_COLLATE</h5>
<p>The rules governing collation depend to some extent on the use. At least five different levels of increasingly complex collation
rules can be distinguished:</p>
<ol>
<li>
<p><i>Byte/machine code order</i>: This is the historical collation order in the UNIX system and many proprietary operating
systems. Collation is here performed character by character, without any regard to context. The primary virtue is that it usually
is quite fast and also completely deterministic; it works well when the native machine collation sequence matches the user
expectations.</p>
</li>
<li>
<p><i>Character order</i>: On this level, collation is also performed character by character, without regard to context. The order
between characters is, however, not determined by the code values, but on the expectations by the user of the &quot;correct&quot; order
between characters. In addition, such a (simple) collation order can specify that certain characters collate equally (for example,
uppercase and lowercase letters).</p>
</li>
<li>
<p><i>String ordering</i>: On this level, entire strings are compared based on relatively straightforward rules. Several &quot;passes''
may be required to determine the order between two strings. Characters may be ignored in some passes, but not in others; the
strings may be compared in different directions; and simple string substitutions may be performed before strings are compared. This
level is best described as &quot;dictionary&quot; ordering; it is based on the spelling, not the pronunciation, or meaning, of the
words.</p>
</li>
<li>
<p><i>Text search ordering</i>: This is a further refinement of the previous level, best described as &quot;telephone book ordering'';
some common homonyms (words spelled differently but with the same pronunciation) are collated together; numbers are collated as if
they were spelled out, and so on.</p>
</li>
<li>
<p><i>Semantic-level ordering</i>: Words and strings are collated based on their meaning; entire words (such as &quot;the&quot;) are
eliminated; the ordering is not deterministic. This usually requires special software and is highly dependent on the intended
use.</p>
</li>
</ol>
<p>While the historical collation order formally is at level 1, for the English language it corresponds roughly to elements at
level 2. The user expects to see the output from the <a href="../utilities/ls.html"><i>ls</i></a> utility sorted very much as it
would be in a dictionary. While telephone book ordering would be an optimal goal for standard collation, this was ruled out as the
order would be language-dependent. Furthermore, a requirement was that the order must be determined solely from the text string and
the collation rules; no external information (for example, &quot;pronunciation dictionaries&quot;) could be required.</p>
<p>As a result, the goal for the collation support is at level 3. This also matches the requirements for the Canadian collation
order, as well as other, known collation requirements for alphabetic scripts. It specifically rules out collation based on
pronunciation rules or based on semantic analysis of the text.</p>
<p>The syntax for the <i>LC_COLLATE</i> category source meets the requirements for level 3 and has been verified to produce the
correct result with examples based on French, Canadian, and Danish collation order. Because it supports multi-character collating
elements, it is also capable of supporting collation in codesets where a character is expressed using non-spacing characters
followed by the base character (such as the ISO/IEC&nbsp;6937:1994 standard).</p>
<p>The directives that can be specified in an operand to the <b>order_start</b> keyword are based on the requirements specified in
several proposed standards and in customary use. The following is a rephrasing of rules defined for &quot;lexical ordering in English
and French&quot; by the Canadian Standards Association (the text in square brackets is rephrased):</p>
<ul>
<li>
<p>Once special characters [punctuation] have been removed from original strings, the ordering is determined by scanning forwards
(left to right) [disregarding case and diacriticals].</p>
</li>
<li>
<p>In case of equivalence, special characters are once again removed from original strings and the ordering is determined by
scanning backwards (starting from the rightmost character of the string and back), character by character [disregarding case but
considering diacriticals].</p>
</li>
<li>
<p>In case of repeated equivalence, special characters are removed again from original strings and the ordering is determined by
scanning forwards, character by character [considering both case and diacriticals].</p>
</li>
<li>
<p>If there is still an ordering equivalence after the first three rules have been applied, then only special characters and the
position they occupy in the string are considered to determine ordering. The string that has a special character in the lowest
position comes first. If two strings have a special character in the same position, the character [with the lowest collation value]
comes first. In case of equality, the other special characters are considered until there is a difference or until all special
characters have been exhausted.</p>
</li>
</ul>
<p>It is estimated that this part of IEEE&nbsp;Std&nbsp;1003.1-2001 covers the requirements for all European languages, and no
particular problems are anticipated with Slavic or Middle East character sets.</p>
<p>The Far East (particularly Japanese/Chinese) collations are often based on contextual information and pronunciation rules (the
same ideogram can have different meanings and different pronunciations). Such collation, in general, falls outside the desired goal
of IEEE&nbsp;Std&nbsp;1003.1-2001. There are, however, several other collation rules (stroke/radical or &quot;most common
pronunciation&quot;) that can be supported with the mechanism described here.</p>
<p>The character order is defined by the order in which characters and elements are specified between the <b>order_start</b> and
<b>order_end</b> keywords. Weights assigned to the characters and elements define the collation sequence; in the absence of
weights, the character order is also the collation sequence.</p>
<p>The <b>position</b> keyword provides the capability to consider, in a compare, the relative position of characters not subject
to <b>IGNORE</b>. As an example, consider the two strings <tt>"o-ring"</tt> and <tt>"or-ing"</tt> . Assuming the hyphen is subject
to <b>IGNORE</b> on the first pass, the two strings compare equal, and the position of the hyphen is immaterial. On second pass,
all characters except the hyphen are subject to <b>IGNORE</b>, and in the normal case the two strings would again compare equal. By
taking position into account, the first collates before the second.</p>
<h5><a name="tag_01_07_03_03"></a>LC_MONETARY</h5>
<p>The currency symbol does not appear in <i>LC_MONETARY</i> because it is not defined in the C locale of the ISO&nbsp;C
standard.</p>
<p>The ISO&nbsp;C standard limits the size of decimal points and thousands delimiters to single-byte values. In locales based on
multi-byte coded character sets, this cannot be enforced; IEEE&nbsp;Std&nbsp;1003.1-2001 does not prohibit such characters, but
makes the behavior unspecified (in the text &quot;In contexts where other standards ...&quot;).</p>
<p>The grouping specification is based on, but not identical to, the ISO&nbsp;C standard. The -1 indicates that no further grouping
is performed; the equivalent of {CHAR_MAX} in the ISO&nbsp;C standard.</p>
<p>The text &quot;the value is not available in the locale&quot; is taken from the ISO&nbsp;C standard and is used instead of the
&quot;unspecified&quot; text in early proposals. There is no implication that omitting these keywords or assigning them values of
<tt>""</tt> or -1 produces unspecified results; such omissions or assignments eliminate the effects described for the keyword or
produce zero-length strings, as appropriate.</p>
<p>The locale definition is an extension of the ISO&nbsp;C standard <a href="../functions/localeconv.html"><i>localeconv</i>()</a>
specification. In particular, rules on how <b>currency_symbol</b> is treated are extended to also cover <b>int_curr_symbol</b>, and
<b>p_set_by_space</b> and <b>n_sep_by_space</b> have been augmented with the value 2, which places a &lt;space&gt; between the sign
and the symbol (if they are adjacent; otherwise, it should be treated as a 0). The following table shows the result of various
combinations:</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="left">
<p class="tent">&nbsp;</p>
</th>
<th align="left">
<p class="tent">&nbsp;</p>
</th>
<th colspan="3" align="center">
<p class="tent"><b>p_sep_by_space</b></p>
</th>
</tr>
<tr valign="top">
<th align="left">
<p class="tent">&nbsp;</p>
</th>
<th align="left">
<p class="tent">&nbsp;</p>
</th>
<th align="center">
<p class="tent"><b>2</b></p>
</th>
<th align="center">
<p class="tent"><b>1</b></p>
</th>
<th align="center">
<p class="tent"><b>0</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><b>p_cs_precedes</b> = 1</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 0</p>
</td>
<td align="left">
<p class="tent">($1.25)</p>
</td>
<td align="left">
<p class="tent">($ 1.25)</p>
</td>
<td align="left">
<p class="tent">($1.25)</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 1</p>
</td>
<td align="left">
<p class="tent">+ $1.25</p>
</td>
<td align="left">
<p class="tent">+$ 1.25</p>
</td>
<td align="left">
<p class="tent">+$1.25</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 2</p>
</td>
<td align="left">
<p class="tent">$1.25 +</p>
</td>
<td align="left">
<p class="tent">$ 1.25+</p>
</td>
<td align="left">
<p class="tent">$1.25+</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 3</p>
</td>
<td align="left">
<p class="tent">+ $1.25</p>
</td>
<td align="left">
<p class="tent">+$ 1.25</p>
</td>
<td align="left">
<p class="tent">+$1.25</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 4</p>
</td>
<td align="left">
<p class="tent">$ +1.25</p>
</td>
<td align="left">
<p class="tent">$+ 1.25</p>
</td>
<td align="left">
<p class="tent">$+1.25</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><b>p_cs_precedes</b> = 0</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 0</p>
</td>
<td align="left">
<p class="tent">(1.25 $)</p>
</td>
<td align="left">
<p class="tent">(1.25 $)</p>
</td>
<td align="left">
<p class="tent">(1.25$)</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 1</p>
</td>
<td align="left">
<p class="tent">+1.25 $</p>
</td>
<td align="left">
<p class="tent">+1.25 $</p>
</td>
<td align="left">
<p class="tent">+1.25$</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 2</p>
</td>
<td align="left">
<p class="tent">1.25$ +</p>
</td>
<td align="left">
<p class="tent">1.25 $+</p>
</td>
<td align="left">
<p class="tent">1.25$+</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 3</p>
</td>
<td align="left">
<p class="tent">1.25+ $</p>
</td>
<td align="left">
<p class="tent">1.25 +$</p>
</td>
<td align="left">
<p class="tent">1.25+$</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">&nbsp;</p>
</td>
<td align="left">
<p class="tent"><b>p_sign_posn</b> = 4</p>
</td>
<td align="left">
<p class="tent">1.25$ +</p>
</td>
<td align="left">
<p class="tent">1.25 $+</p>
</td>
<td align="left">
<p class="tent">1.25$+</p>
</td>
</tr>
</table>
</center>
<p>The following is an example of the interpretation of the <b>mon_grouping</b> keyword. Assuming that the value to be formatted is
123456789 and the <b>mon_thousands_sep</b> is <tt>'&quot;</tt> , then the following table shows the result. The third column shows the
equivalent string in the ISO&nbsp;C standard that would be used by the <a href=
"../functions/localeconv.html"><i>localeconv</i>()</a> function to accommodate this grouping.</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="center">
<p class="tent"><b>mon_grouping</b></p>
</th>
<th align="center">
<p class="tent"><b>Formatted Value</b></p>
</th>
<th align="center">
<p class="tent"><b>ISO C String</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">3;-1</p>
</td>
<td align="left">
<p class="tent">123456'789</p>
</td>
<td align="left">
<p class="tent">"\3\177"</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">3</p>
</td>
<td align="left">
<p class="tent">123'456'789</p>
</td>
<td align="left">
<p class="tent">"\3"</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">3;2;-1</p>
</td>
<td align="left">
<p class="tent">1234'56'789</p>
</td>
<td align="left">
<p class="tent">"\3\2\177"</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">3;2</p>
</td>
<td align="left">
<p class="tent">12'34'56'789</p>
</td>
<td align="left">
<p class="tent">"\3\2"</p>
</td>
</tr>
<tr valign="top">
<td align="left">
<p class="tent">-1</p>
</td>
<td align="left">
<p class="tent">123456789</p>
</td>
<td align="left">
<p class="tent">"\177"</p>
</td>
</tr>
</table>
</center>
<p>In these examples, the octal value of {CHAR_MAX} is 177.</p>
<h5><a name="tag_01_07_03_04"></a>LC_NUMERIC</h5>
<p>See the rationale for <i>LC_MONETARY</i> for a description of the behavior of grouping.</p>
<h5><a name="tag_01_07_03_05"></a>LC_TIME</h5>
<p>Although certain of the conversion specifications in the POSIX locale (such as the name of the month) are shown with initial
capital letters, this need not be the case in other locales. Programs using these conversion specifications may need to adjust the
capitalization if the output is going to be used at the beginning of a sentence.</p>
<p>The <i>LC_TIME</i> descriptions of <b>abday</b>, <b>day</b>, <b>mon</b>, and <b>abmon</b> imply a Gregorian style calendar
(7-day weeks, 12-month years, leap years, and so on). Formatting time strings for other types of calendars is outside the scope of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>While the ISO&nbsp;8601:2000 standard numbers the weekdays starting with Monday, historical practice is to use the Sunday as the
first day. Rather than change the order and introduce potential confusion, the days must be specified beginning with Sunday;
previous references to &quot;first day&quot; have been removed. Note also that the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 <a href="../utilities/date.html"><i>date</i></a> utility supports numbering compliant with the
ISO&nbsp;8601:2000 standard.</p>
<p>As specified under <a href="../utilities/date.html"><i>date</i></a> in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 and <a href="../functions/strftime.html"><i>strftime</i>()</a> in the System Interfaces volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, the conversion specifications corresponding to the optional keywords consist of a modifier followed
by a traditional conversion specification (for instance, <tt>%Ex</tt> ). If the optional keywords are not supported by the
implementation or are unspecified for the current locale, these modified conversion specifications are treated as the traditional
conversion specifications. For example, assume the following keywords:</p>
<blockquote>
<pre>
<tt>alt_digits "0th";"1st";"2nd";"3rd";"4th";"5th";\
"6th";"7th";"8th";"9th";"10th"
<br>
d_fmt "The %Od day of %B in %Y"
</tt>
</pre>
</blockquote>
<p>On July 4th 1776, the <tt>%x</tt> conversion specifications would result in <tt>"The 4th day of July in 1776"</tt> , while on
July 14th 1789 it would result in <tt>"The 14 day of July in 1789"</tt> . It can be noted that the above example is for
illustrative purposes only; the <tt>%O</tt> modifier is primarily intended to provide for Kanji or Hindi digits in <a href=
"../utilities/date.html"><i>date</i></a> formats.</p>
<p>The following is an example for Japan that supports the current plus last three Emperors and reverts to Western style numbering
for years prior to the Meiji era. The example also allows for the custom of using a special name for the first year of an era
instead of using 1. (The examples substitute romaji where kanji should be used.)</p>
<blockquote>
<pre>
<tt>era_d_fmt "%EY%mgatsu%dnichi (%a)"
<br>
era "+:2:1990/01/01:+*:Heisei:%EC%Eynen";\
"+:1:1989/01/08:1989/12/31:Heisei:%ECgannen";\
"+:2:1927/01/01:1989/01/07:Shouwa:%EC%Eynen";\
"+:1:1926/12/25:1926/12/31:Shouwa:%ECgannen";\
"+:2:1913/01/01:1926/12/24:Taishou:%EC%Eynen";\
"+:1:1912/07/30:1912/12/31:Taishou:%ECgannen";\
"+:2:1869/01/01:1912/07/29:Meiji:%EC%Eynen";\
"+:1:1868/09/08:1868/12/31:Meiji:%ECgannen";\
"-:1868:1868/09/07:-*::%Ey"
</tt>
</pre>
</blockquote>
<p>Assuming that the current date is September 21, 1991, a request to <a href="../utilities/date.html"><i>date</i></a> or <a href=
"../functions/strftime.html"><i>strftime</i>()</a> would yield the following results:</p>
<blockquote>
<pre>
<tt>%Ec - Heisei3nen9gatsu21nichi (Sat) 14:39:26
%EC - Heisei
%Ex - Heisei3nen9gatsu21nichi (Sat)
%Ey - 3
%EY - Heisei3nen
</tt>
</pre>
</blockquote>
<p>Example era definitions for the Republic of China:</p>
<blockquote>
<pre>
<tt>era "+:2:1913/01/01:+*:ChungHwaMingGuo:%EC%EyNen";\
"+:1:1912/1/1:1912/12/31:ChungHwaMingGuo:%ECYuenNen";\
"+:1:1911/12/31:-*:MingChien:%EC%EyNen"
</tt>
</pre>
</blockquote>
<p>Example definitions for the Christian Era:</p>
<blockquote>
<pre>
<tt>era "+:1:0001/01/01:+*:AD:%EC %Ey";\
"+:1:-0001/12/31:-*:BC:%Ey %EC"
</tt>
</pre>
</blockquote>
<h5><a name="tag_01_07_03_06"></a>LC_MESSAGES</h5>
<p>The <b>yesstr</b> and <b>nostr</b> locale keywords and the YESSTR and NOSTR <i>langinfo</i> items were formerly used to match
user affirmative and negative responses. In IEEE&nbsp;Std&nbsp;1003.1-2001, the <b>yesexpr</b>, <b>noexpr</b>, YESEXPR, and NOEXPR
extended regular expressions have replaced them. Applications should use the general locale-based messaging facilities to issue
prompting messages which include sample desired responses.</p>
<h4><a name="tag_01_07_04"></a>Locale Definition Grammar</h4>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_07_04_01"></a>Locale Lexical Conventions</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_07_04_02"></a>Locale Grammar</h5>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_07_05"></a>Locale Definition Example</h4>
<p>The following is an example of a locale definition file that could be used as input to the <a href=
"../utilities/localedef.html"><i>localedef</i></a> utility. It assumes that the utility is executed with the <b>-f</b> option,
naming a charmap file with (at least) the following content:</p>
<blockquote>
<pre>
<tt>CHARMAP
&lt;space&gt; \x20
&lt;dollar&gt; \x24
&lt;A&gt; \101
&lt;a&gt; \141
&lt;A-acute&gt; \346
&lt;a-acute&gt; \365
&lt;A-grave&gt; \300
&lt;a-grave&gt; \366
&lt;b&gt; \142
&lt;C&gt; \103
&lt;c&gt; \143
&lt;c-cedilla&gt; \347
&lt;d&gt; \x64
&lt;H&gt; \110
&lt;h&gt; \150
&lt;eszet&gt; \xb7
&lt;s&gt; \x73
&lt;z&gt; \x7a
END CHARMAP
</tt>
</pre>
</blockquote>
<p>It should not be taken as complete or to represent any actual locale, but only to illustrate the syntax.</p>
<pre>
<tt>#
LC_CTYPE
lower &lt;a&gt;;&lt;b&gt;;&lt;c&gt;;&lt;c-cedilla&gt;;&lt;d&gt;;...;&lt;z&gt;
upper A;B;C;&Ccedil;;...;Z
space \x20;\x09;\x0a;\x0b;\x0c;\x0d
blank \040;\011
toupper (&lt;a&gt;,&lt;A&gt;);(b,B);(c,C);(&ccedil;,&Ccedil;);(d,D);(z,Z)
END LC_CTYPE
#
LC_COLLATE
#
# The following example of collation is based on
# Canadian standard Z243.4.1-1998, "Canadian Alphanumeric
# Ordering Standard for Character Sets of CSA Z234.4 Standard".
# (Other parts of this example locale definition file do not
# purport to relate to Canada, or to any other real culture.)
# The proposed standard defines a 4-weight collation, such that
# in the first pass, characters are compared without regard to
# case or accents; in the second pass, backwards-compare without
# regard to case; in the third pass, forwards-compare without
# regard to diacriticals. In the 3 first passes, non-alphabetic
# characters are ignored; in the fourth pass, only special
# characters are considered, such that "The string that has a
# special character in the lowest position comes first. If two
# strings have a special character in the same position, the
# collation value of the special character determines ordering.
#
# Only a subset of the character set is used here; mostly to
# illustrate the set-up.
#
collating-symbol &lt;NULL&gt;
collating-symbol &lt;LOW_VALUE&gt;
collating-symbol &lt;LOWER-CASE&gt;
collating-symbol &lt;SUBSCRIPT-LOWER&gt;
collating-symbol &lt;SUPERSCRIPT-LOWER&gt;
collating-symbol &lt;UPPER-CASE&gt;
collating-symbol &lt;NO-ACCENT&gt;
collating-symbol &lt;PECULIAR&gt;
collating-symbol &lt;LIGATURE&gt;
collating-symbol &lt;ACUTE&gt;
collating-symbol &lt;GRAVE&gt;
# Further collating-symbols follow.
#
# Properly, the standard does not include any multi-character
# collating elements; the one below is added for completeness.
#
collating_element &lt;ch&gt; from "&lt;c&gt;&lt;h&gt;"
collating_element &lt;CH&gt; from "&lt;C&gt;&lt;H&gt;"
collating_element &lt;Ch&gt; from "&lt;C&gt;&lt;h&gt;"
#
order_start forward;backward;forward;forward,position
#
# Collating symbols are specified first in the sequence to allocate
# basic collation values to them, lower than that of any character.
&lt;NULL&gt;
&lt;LOW_VALUE&gt;
&lt;LOWER-CASE&gt;
&lt;SUBSCRIPT-LOWER&gt;
&lt;SUPERSCRIPT-LOWER&gt;
&lt;UPPER-CASE&gt;
&lt;NO-ACCENT&gt;
&lt;PECULIAR&gt;
&lt;LIGATURE&gt;
&lt;ACUTE&gt;
&lt;GRAVE&gt;
&lt;RING-ABOVE&gt;
&lt;DIAERESIS&gt;
&lt;TILDE&gt;
# Further collating symbols are given a basic collating value here.
#
# Here follow special characters.
&lt;space&gt; IGNORE;IGNORE;IGNORE;&lt;space&gt;
# Other special characters follow here.
#
# Here follow the regular characters.
&lt;a&gt; &lt;a&gt;;&lt;NO-ACCENT&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;A&gt; &lt;a&gt;;&lt;NO-ACCENT&gt;;&lt;UPPER-CASE&gt;;IGNORE
&lt;a-acute&gt; &lt;a&gt;;&lt;ACUTE&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;A-acute&gt; &lt;a&gt;;&lt;ACUTE&gt;;&lt;UPPER-CASE&gt;;IGNORE
&lt;a-grave&gt; &lt;a&gt;;&lt;GRAVE&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;A-grave&gt; &lt;a&gt;;&lt;GRAVE&gt;;&lt;UPPER-CASE&gt;;IGNORE
&lt;ae&gt; "&lt;a&gt;&lt;e&gt;";"&lt;LIGATURE&gt;&lt;LIGATURE&gt;";\
"&lt;LOWER-CASE&gt;&lt;LOWER-CASE&gt;";IGNORE
&lt;AE&gt; "&lt;a&gt;&lt;e&gt;";"&lt;LIGATURE&gt;&lt;LIGATURE&gt;";\
"&lt;UPPER-CASE&gt;&lt;UPPER-CASE&gt;";IGNORE
&lt;b&gt; &lt;b&gt;;&lt;NO-ACCENT&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;B&gt; &lt;b&gt;;&lt;NO-ACCENT&gt;;&lt;UPPER-CASE&gt;;IGNORE
&lt;c&gt; &lt;c&gt;;&lt;NO-ACCENT&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;C&gt; &lt;c&gt;;&lt;NO-ACCENT&gt;;&lt;UPPER-CASE&gt;;IGNORE
&lt;ch&gt; &lt;ch&gt;;&lt;NO-ACCENT&gt;;&lt;LOWER-CASE&gt;;IGNORE
&lt;Ch&gt; &lt;ch&gt;;&lt;NO-ACCENT&gt;;&lt;PECULIAR&gt;;IGNORE
&lt;CH&gt; &lt;ch&gt;;&lt;NO-ACCENT&gt;;&lt;UPPER-CASE&gt;;IGNORE
#
# As an example, the strings "Bach" and "bach" could be encoded (for
# compare purposes) as:
# "Bach" &lt;b&gt;;&lt;a&gt;;&lt;ch&gt;;&lt;LOW_VALUE&gt;;&lt;NO_ACCENT&gt;;&lt;NO_ACCENT&gt;;\
# &lt;NO_ACCENT&gt;;&lt;LOW_VALUE&gt;;&lt;UPPER-CASE&gt;;&lt;LOWER-CASE&gt;;\
# &lt;LOWER-CASE&gt;;&lt;NULL&gt;
# "bach" &lt;b&gt;;&lt;a&gt;;&lt;ch&gt;;&lt;LOW_VALUE&gt;;&lt;NO_ACCENT&gt;;&lt;NO_ACCENT&gt;;\
# &lt;NO_ACCENT&gt;;&lt;LOW_VALUE&gt;;&lt;LOWER-CASE&gt;;&lt;LOWER-CASE&gt;;\
# &lt;LOWER-CASE&gt;;&lt;NULL&gt;
#
# The two strings are equal in pass 1 and 2, but differ in pass 3.
#
# Further characters follow.
#
UNDEFINED IGNORE;IGNORE;IGNORE;IGNORE
#
order_end
#
END LC_COLLATE
#
LC_MONETARY
int_curr_symbol "USD "
currency_symbol "$"
mon_decimal_point "."
mon_grouping 3;0
positive_sign ""
negative_sign "-"
p_cs_precedes 1
n_sign_posn 0
END LC_MONETARY
#
LC_NUMERIC
copy "US_en.ASCII"
END LC_NUMERIC
#
LC_TIME
abday "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat"
#
day "Sunday";"Monday";"Tuesday";"Wednesday";\
"Thursday";"Friday";"Saturday"
#
abmon "Jan";"Feb";"Mar";"Apr";"May";"Jun";\
"Jul";"Aug";"Sep";"Oct";"Nov";"Dec"
#
mon "January";"February";"March";"April";\
"May";"June";"July";"August";"September";\
"October";"November";"December"
#
d_t_fmt "%a %b %d %T %Z %Y\n"
END LC_TIME
#
LC_MESSAGES
yesexpr "^([yY][[:alpha:]]*)|(OK)"
#
noexpr "^[nN][[:alpha:]]*"
END LC_MESSAGES
</tt>
</pre>
<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>

169
Ref-docs/POSIX/susv3/xrat/xbd_chap08.html Normal file
View File

@@ -0,0 +1,169 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_08"></a>Environment Variables</h3>
<h4><a name="tag_01_08_01"></a>Environment Variable Definition</h4>
<p>The variable <i>environ</i> is not intended to be declared in any header, but rather to be declared by the user for accessing
the array of strings that is the environment. This is the traditional usage of the symbol. Putting it into a header could break
some programs that use the symbol for their own purposes.</p>
<p>The decision to restrict conforming systems to the use of digits, uppercase letters, and underscores for environment variable
names allows applications to use lowercase letters in their environment variable names without conflicting with any conforming
system.</p>
<p>In addition to the obvious conflict with the shell syntax for positional parameter substitution, some historical applications
(including some shells) exclude names with leading digits from the environment.</p>
<h4><a name="tag_01_08_02"></a>Internationalization Variables</h4>
<p>The text about locale implies that any utilities written in standard C and conforming to IEEE&nbsp;Std&nbsp;1003.1-2001 must
issue the following call:</p>
<blockquote>
<pre>
<tt>setlocale(LC_ALL, "")
</tt>
</pre>
</blockquote>
<p>If this were omitted, the ISO&nbsp;C standard specifies that the C locale would be used.</p>
<p>If any of the environment variables are invalid, it makes sense to default to an implementation-defined, consistent locale
environment. It is more confusing for a user to have partial settings occur in case of a mistake. All utilities would then behave
in one language/cultural environment. Furthermore, it provides a way of forcing the whole environment to be the
implementation-defined default. Disastrous results could occur if a pipeline of utilities partially uses the environment variables
in different ways. In this case, it would be appropriate for utilities that use <i>LANG</i> and related variables to exit with an
error if any of the variables are invalid. For example, users typing individual commands at a terminal might want <a href=
"../utilities/date.html"><i>date</i></a> to work if <i>LC_MONETARY</i> is invalid as long as <i>LC_TIME</i> is valid. Since these
are conflicting reasonable alternatives, IEEE&nbsp;Std&nbsp;1003.1-2001 leaves the results unspecified if the locale environment
variables would not produce a complete locale matching the specification of the user.</p>
<p>The locale settings of individual categories cannot be truly independent and still guarantee correct results. For example, when
collating two strings, characters must first be extracted from each string (governed by <i>LC_CTYPE )</i> before being mapped to
collating elements (governed by <i>LC_COLLATE )</i> for comparison. That is, if <i>LC_CTYPE</i> is causing parsing according to the
rules of a large, multi-byte code set (potentially returning 20000 or more distinct character codeset values), but
<i>LC_COLLATE</i> is set to handle only an 8-bit codeset with 256 distinct characters, meaningful results are obviously
impossible.</p>
<p>The <i>LC_MESSAGES</i> variable affects the language of messages generated by the standard utilities.</p>
<p>The description of the environment variable names starting with the characters &quot;LC_&quot; acknowledges the fact that the interfaces
presented may be extended as new international functionality is required. In the ISO&nbsp;C standard, names preceded by &quot;LC_&quot; are
reserved in the name space for future categories.</p>
<p>To avoid name clashes, new categories and environment variables are divided into two classifications:
&quot;implementation-independent&quot; and &quot;implementation-defined&quot;.</p>
<p>Implementation-independent names will have the following format:</p>
<blockquote>
<pre>
<tt>LC_</tt><i>NAME</i>
</pre>
</blockquote>
<p>where <i>NAME</i> is the name of the new category and environment variable. Capital letters must be used for
implementation-independent names.</p>
<p>Implementation-defined names must be in lowercase letters, as below:</p>
<blockquote>
<pre>
<tt>LC_</tt><i>name</i>
</pre>
</blockquote>
<h4><a name="tag_01_08_03"></a>Other Environment Variables</h4>
<h5><a name="tag_01_08_03_01"></a>COLUMNS, LINES</h5>
<p>The default values for the number of column positions, <i>COLUMNS ,</i> and screen height, <i>LINES ,</i> are unspecified
because historical implementations use different methods to determine values corresponding to the size of the screen in which the
utility is run. This size is typically known to the implementation through the value of <i>TERM ,</i> or by more elaborate methods
such as extensions to the <a href="../utilities/stty.html"><i>stty</i></a> utility or knowledge of how the user is dynamically
resizing windows on a bit-mapped display terminal. Users should not need to set these variables in the environment unless there is
a specific reason to override the default behavior of the implementation, such as to display data in an area arbitrarily smaller
than the terminal or window. Values for these variables that are not decimal integers greater than zero are implicitly undefined
values; it is unnecessary to enumerate all of the possible values outside of the acceptable set.</p>
<h5><a name="tag_01_08_03_02"></a>LOGNAME</h5>
<p>In most implementations, the value of such a variable is easily forged, so security-critical applications should rely on other
means of determining user identity. <i>LOGNAME</i> is required to be constructed from the portable filename character set for
reasons of interchange. No diagnostic condition is specified for violating this rule, and no requirement for enforcement exists.
The intent of the requirement is that if extended characters are used, the &quot;guarantee&quot; of portability implied by a standard is
void.</p>
<h5><a name="tag_01_08_03_03"></a>PATH</h5>
<p>Many historical implementations of the Bourne shell do not interpret a trailing colon to represent the current working directory
and are thus non-conforming. The C Shell and the KornShell conform to IEEE&nbsp;Std&nbsp;1003.1-2001 on this point. The usual name
of dot may also be used to refer to the current working directory.</p>
<p>Many implementations historically have used a default value of <b>/bin</b> and <b>/usr/bin</b> for the <i>PATH</i> variable.
IEEE&nbsp;Std&nbsp;1003.1-2001 does not mandate this default path be identical to that retrieved from <i>getconf</i> _CS_PATH
because it is likely that the standardized utilities may be provided in another directory separate from the directories used by
some historical applications.</p>
<h5><a name="tag_01_08_03_04"></a>SHELL</h5>
<p>The <i>SHELL</i> variable names the preferred shell of the user; it is a guide to applications. There is no direct requirement
that that shell conform to IEEE&nbsp;Std&nbsp;1003.1-2001; that decision should rest with the user. It is the intention of the
standard developers that alternative shells be permitted, if the user chooses to develop or acquire one. An operating system that
builds its shell into the &quot;kernel&quot; in such a manner that alternative shells would be impossible does not conform to the spirit of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<h5><a name="tag_01_08_03_05"></a>TZ</h5>
<p>The quoted form of the timezone variable allows timezone names of the form UTC+1 (or any name that contains the character plus (
<tt>'+'</tt> ), the character minus ( <tt>'-'</tt> ), or digits), which may be appropriate for countries that do not have an
official timezone name. It would be coded as &lt;UTC+1&gt;+1&lt;UTC+2&gt;, which would cause <i>std</i> to have a value of UTC+1
and <i>dst</i> a value of UTC+2, each with a length of 5 characters. This does not appear to conflict with any existing usage. The
characters <tt>'&lt;'</tt> and <tt>'&gt;'</tt> were chosen for quoting because they are easier to parse visually than a quoting
character that does not provide some sense of bracketing (and in a string like this, such bracketing is helpful). They were also
chosen because they do not need special treatment when assigning to the <i>TZ</i> variable. Users are often confused by embedding
quotes in a string. Because <tt>'&lt;'</tt> and <tt>'&gt;'</tt> are meaningful to the shell, the whole string would have to be
quoted, but that is easily explained. (Parentheses would have presented the same problems.) Although the <tt>'&gt;'</tt> symbol
could have been permitted in the string by either escaping it or doubling it, it seemed of little value to require that. This could
be provided as an extension if there was a need. Timezone names of this new form lead to a requirement that the value of
{_POSIX_TZNAME_MAX} change from 3 to 6.</p>
<p>Since the <i>TZ</i> environment variable is usually inherited by all applications started by a user after the value of the
<i>TZ</i> environment variable is changed and since many applications run using the C or POSIX locale, using characters that are
not in the portable character set in the <i>std</i> and <i>dst</i> fields could cause unexpected results.</p>
<p>The format of the <i>TZ</i> environment variable is changed in Issue 6 to allow for the quoted form, as defined in previous
versions of the ISO&nbsp;POSIX-1 standard.</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>

401
Ref-docs/POSIX/susv3/xrat/xbd_chap09.html Normal file
View File

@@ -0,0 +1,401 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_09"></a>Regular Expressions</h3>
<p>Rather than repeating the description of REs for each utility supporting REs, the standard developers preferred a common,
comprehensive description of regular expressions in one place. The most common behavior is described here, and exceptions or
extensions to this are documented for the respective utilities, as appropriate.</p>
<p>The BRE corresponds to the <a href="../utilities/ed.html"><i>ed</i></a> or historical <a href=
"../utilities/grep.html"><i>grep</i></a> type, and the ERE corresponds to the historical <i>egrep</i> type (now <a href=
"../utilities/grep.html"><i>grep</i></a> <b>-E</b>).</p>
<p>The text is based on the <a href="../utilities/ed.html"><i>ed</i></a> description and substantially modified, primarily to aid
developers and others in the understanding of the capabilities and limitations of REs. Much of this was influenced by
internationalization requirements.</p>
<p>It should be noted that the definitions in this section do not cover the <a href="../utilities/tr.html"><i>tr</i></a> utility;
the <a href="../utilities/tr.html"><i>tr</i></a> syntax does not employ REs.</p>
<p>The specification of REs is particularly important to internationalization because pattern matching operations are very basic
operations in business and other operations. The syntax and rules of REs are intended to be as intuitive as possible to make them
easy to understand and use. The historical rules and behavior do not provide that capability to non-English language users, and do
not provide the necessary support for commonly used characters and language constructs. It was necessary to provide extensions to
the historical RE syntax and rules to accommodate other languages.</p>
<p>As they are limited to bracket expressions, the rationale for these modifications is in the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap09.html#tag_09_03_05">Section 9.3.5, RE Bracket Expression</a>.</p>
<h4><a name="tag_01_09_01"></a>Regular Expression Definitions</h4>
<p>It is possible to determine what strings correspond to subexpressions by recursively applying the leftmost longest rule to each
subexpression, but only with the proviso that the overall match is leftmost longest. For example, matching
<tt>"\(ac*\)c*d[ac]*\1"</tt> against <i>acdacaaa</i> matches <i>acdacaaa</i> (with \1=<i>a</i>); simply matching the longest match
for <tt>"\(ac*\)"</tt> would yield \1=<i>ac</i>, but the overall match would be smaller (<i>acdac</i>). Conceptually, the
implementation must examine every possible match and among those that yield the leftmost longest total matches, pick the one that
does the longest match for the leftmost subexpression, and so on. Note that this means that matching by subexpressions is
context-dependent: a subexpression within a larger RE may match a different string from the one it would match as an independent
RE, and two instances of the same subexpression within the same larger RE may match different lengths even in similar sequences of
characters. For example, in the ERE <tt>"(a.*b)(a.*b)"</tt> , the two identical subexpressions would match four and six characters,
respectively, of <i>accbaccccb</i>.</p>
<p>The definition of single character has been expanded to include also collating elements consisting of two or more characters;
this expansion is applicable only when a bracket expression is included in the BRE or ERE. An example of such a collating element
may be the Dutch <i>ij</i>, which collates as a <tt>'y'</tt> . In some encodings, a ligature &quot;i with j&quot; exists as a character and
would represent a single-character collating element. In another encoding, no such ligature exists, and the two-character sequence
<i>ij</i> is defined as a multi-character collating element. Outside brackets, the <i>ij</i> is treated as a two-character RE and
matches the same characters in a string. Historically, a bracket expression only matched a single character. The
ISO&nbsp;POSIX-2:1993 standard required bracket expressions like <tt>"[^[:lower:]]"</tt> to match multi-character collating
elements such as <tt>"ij"</tt> . However, this requirement led to behavior that many users did not expect and that could not
feasibly be mimicked in user code, and it was rarely if ever implemented correctly. The current standard leaves it unspecified
whether a bracket expression matches a multi-character collating element, allowing both historical and ISO&nbsp;POSIX-2:1993
standard implementations to conform.</p>
<p>Also, in the current standard, it is unspecified whether character class expressions like <tt>"[:lower:]"</tt> can include
multi-character collating elements like <tt>"ij"</tt> ; hence <tt>"[[:lower:]]"</tt> can match <tt>"ij"</tt> , and
<tt>"[^[:lower:]]"</tt> can fail to match <tt>"ij"</tt> . Common practice is for a character class expression to match a collating
element if it matches the collating element's first character.</p>
<h4><a name="tag_01_09_02"></a>Regular Expression General Requirements</h4>
<p>The definition of which sequence is matched when several are possible is based on the leftmost-longest rule historically used by
deterministic recognizers. This rule is easier to define and describe, and arguably more useful, than the first-match rule
historically used by non-deterministic recognizers. It is thought that dependencies on the choice of rule are rare; carefully
contrived examples are needed to demonstrate the difference.</p>
<p>A formal expression of the leftmost-longest rule is:</p>
<blockquote>The search is performed as if all possible suffixes of the string were tested for a prefix matching the pattern; the
longest suffix containing a matching prefix is chosen, and the longest possible matching prefix of the chosen suffix is identified
as the matching sequence.</blockquote>
<p>Historically, most RE implementations only match lines, not strings. However, that is more an effect of the usage than of an
inherent feature of REs themselves. Consequently, IEEE&nbsp;Std&nbsp;1003.1-2001 does not regard &lt;newline&gt;s as special; they
are ordinary characters, and both a period and a non-matching list can match them. Those utilities (like <a href=
"../utilities/grep.html"><i>grep</i></a>) that do not allow &lt;newline&gt;s to match are responsible for eliminating any
&lt;newline&gt; from strings before matching against the RE. The <a href="../functions/regcomp.html"><i>regcomp</i>()</a> function,
however, can provide support for such processing without violating the rules of this section.</p>
<p>Some implementations of <i>egrep</i> have had very limited flexibility in handling complex EREs. IEEE&nbsp;Std&nbsp;1003.1-2001
does not attempt to define the complexity of a BRE or ERE, but does place a lower limit on it-any RE must be handled, as long as it
can be expressed in 256 bytes or less. (Of course, this does not place an upper limit on the implementation.) There are historical
programs using a non-deterministic-recognizer implementation that should have no difficulty with this limit. It is possible that a
good approach would be to attempt to use the faster, but more limited, deterministic recognizer for simple expressions and to fall
back on the non-deterministic recognizer for those expressions requiring it. Non-deterministic implementations must be careful to
observe the rules on which match is chosen; the longest match, not the first match, starting at a given character is used.</p>
<p>The term &quot;invalid&quot; highlights a difference between this section and some others: IEEE&nbsp;Std&nbsp;1003.1-2001 frequently
avoids mandating of errors for syntax violations because they can be used by implementors to trigger extensions. However, the
authors of the internationalization features of REs wanted to mandate errors for certain conditions to identify usage problems or
non-portable constructs. These are identified within this rationale as appropriate. The remaining syntax violations have been left
implicitly or explicitly undefined. For example, the BRE construct <tt>"\{1,2,3\}"</tt> does not comply with the grammar. A
conforming application cannot rely on it producing an error nor matching the literal characters <tt>"\{1,2,3\}"</tt> . The term
&quot;undefined&quot; was used in favor of &quot;unspecified&quot; because many of the situations are considered errors on some implementations,
and the standard developers considered that consistency throughout the section was preferable to mixing undefined and
unspecified.</p>
<h4><a name="tag_01_09_03"></a>Basic Regular Expressions</h4>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_01"></a>BREs Matching a Single Character or Collating Element</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_02"></a>BRE Ordinary Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_03"></a>BRE Special Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_04"></a>Periods in BREs</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_05"></a>RE Bracket Expression</h5>
<p>Range expressions are, historically, an integral part of REs. However, the requirements of &quot;natural language behavior&quot; and
portability do conflict. In the POSIX locale, ranges must be treated according to the collating sequence and include such
characters that fall within the range based on that collating sequence, regardless of character values. In other locales, ranges
have unspecified behavior.</p>
<p>Some historical implementations allow range expressions where the ending range point of one range is also the starting point of
the next (for instance, <tt>"[a-m-o]"</tt> ). This behavior should not be permitted, but to avoid breaking historical
implementations, it is now <i>undefined</i> whether it is a valid expression and how it should be interpreted.</p>
<p>Current practice in <a href="../utilities/awk.html"><i>awk</i></a> and <a href="../utilities/lex.html"><i>lex</i></a> is to
accept escape sequences in bracket expressions as per the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, Table 5-1,
Escape Sequences and Associated Actions, while the normal ERE behavior is to regard such a sequence as consisting of two
characters. Allowing the <a href="../utilities/awk.html"><i>awk</i></a>/ <a href="../utilities/lex.html"><i>lex</i></a> behavior in
EREs would change the normal behavior in an unacceptable way; it is expected that <a href="../utilities/awk.html"><i>awk</i></a>
and <a href="../utilities/lex.html"><i>lex</i></a> will decode escape sequences in EREs before passing them to <a href=
"../functions/regcomp.html"><i>regcomp</i>()</a> or comparable routines. Each utility describes the escape sequences it accepts as
an exception to the rules in this section; the list is not the same, for historical reasons.</p>
<p>As noted previously, the new syntax and rules have been added to accommodate other languages than English. The remainder of this
section describes the rationale for these modifications.</p>
<p>In the POSIX locale, a regular expression that starts with a range expression matches a set of strings that are contiguously
sorted, but this is not necessarily true in other locales. For example, a French locale might have the following behavior:</p>
<pre>
<b>$</b> <tt>ls
alpha Alpha estim&eacute; ESTIM&eacute; &eacute;t&eacute; eur&ecirc;ka
</tt><b>$</b> <tt>ls [a-e]*
alpha Alpha estim&eacute; eur&ecirc;ka
</tt>
</pre>
<p>Such disagreements between matching and contiguous sorting are unavoidable because POSIX sorting cannot be implemented in terms
of a deterministic finite-state automaton (DFA), but range expressions by design are implementable in terms of DFAs.</p>
<p>Historical implementations used native character order to interpret range expressions. The ISO&nbsp;POSIX-2:1993 standard
instead required collating element order (CEO): the order that collating elements were specified between the <b>order_start</b> and
<b>order_end</b> keywords in the <i>LC_COLLATE</i> category of the current locale. CEO had some advantages in portability over the
native character order, but it also had some disadvantages:</p>
<ul>
<li>
<p>CEO could not feasibly be mimicked in user code, leading to inconsistencies between POSIX matchers and matchers in popular user
programs like Emacs, <i>ksh</i>, and Perl.</p>
</li>
<li>
<p>CEO caused range expressions to match accented and capitalized letters contrary to many users' expectations. For example,
<tt>"[a-e]"</tt> typically matched both <tt>'E'</tt> and <tt>'&aacute;'</tt> but neither <tt>'A'</tt> nor <tt>'&eacute;'</tt> .</p>
</li>
<li>
<p>CEO was not consistent across implementations. In practice, CEO was often less portable than native character order. For
example, it was common for the CEOs of two implementation-supplied locales to disagree, even if both locales were named
<tt>"da_DK"</tt> .</p>
</li>
</ul>
<p>Because of these problems, some implementations of regular expressions continued to use native character order. Others used the
collation sequence, which is more consistent with sorting than either CEO or native order, but which departs further from the
traditional POSIX semantics because it generally requires <tt>"[a-e]"</tt> to match either <tt>'A'</tt> or <tt>'E'</tt> but not
both. As a result of this kind of implementation variation, programmers who wanted to write portable regular expressions could not
rely on the ISO&nbsp;POSIX-2:1993 standard guarantees in practice.</p>
<p>While revising the standard, lengthy consideration was given to proposals to attack this problem by adding an API for querying
the CEO to allow user-mode matchers, but none of these proposals had implementation experience and none achieved consensus. Leaving
the standard alone was also considered, but rejected due to the problems described above.</p>
<p>The current standard leaves unspecified the behavior of a range expression outside the POSIX locale. This makes it clearer that
conforming applications should avoid range expressions outside the POSIX locale, and it allows implementations and compatible
user-mode matchers to interpret range expressions using native order, CEO, collation sequence, or other, more advanced techniques.
The concerns which led to this change were raised in IEEE PASC interpretation 1003.2 #43 and others, and related to ambiguities in
the specification of how multi-character collating elements should be handled in range expressions. These ambiguities had led to
multiple interpretations of the specification, in conflicting ways, which led to varying implementations. As noted above, efforts
were made to resolve the differences, but no solution has been found that would be specific enough to allow for portable software
while not invalidating existing implementations.</p>
<p>The standard developers recognize that collating elements are important, such elements being common in several European
languages; for example, <tt>'ch'</tt> or <tt>'ll'</tt> in traditional Spanish; <tt>'aa'</tt> in several Scandinavian languages.
Existing internationalized implementations have processed, and continue to process, these elements in range expressions. Efforts
are expected to continue in the future to find a way to define the behavior of these elements precisely and portably.</p>
<p>The ISO&nbsp;POSIX-2:1993 standard required <tt>"[b-a]"</tt> to be an invalid expression in the POSIX locale, but this
requirement has been relaxed in this version of the standard so that <tt>"[b-a]"</tt> can instead be treated as a valid expression
that does not match any string.</p>
<h5><a name="tag_01_09_03_06"></a>BREs Matching Multiple Characters</h5>
<p>The limit of nine back-references to subexpressions in the RE is based on the use of a single-digit identifier; increasing this
to multiple digits would break historical applications. This does not imply that only nine subexpressions are allowed in REs. The
following is a valid BRE with ten subexpressions:</p>
<pre>
<tt>\(\(\(ab\)*c\)*d\)\(ef\)*\(gh\)\{2\}\(ij\)*\(kl\)*\(mn\)*\(op\)*\(qr\)*
</tt>
</pre>
<p>The standard developers regarded the common historical behavior, which supported <tt>"\n*"</tt> , but not
<tt>"\n\{min,max\}"</tt> , <tt>"\(...\)*"</tt> , or <tt>"\(...\)\{min,max\}"</tt> , as a non-intentional result of a specific
implementation, and they supported both duplication and interval expressions following subexpressions and back-references.</p>
<p>The changes to the processing of the back-reference expression remove an unspecified or ambiguous behavior in the Shell and
Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, aligning it with the requirements specified for the <a href=
"../functions/regcomp.html"><i>regcomp</i>()</a> expression, and is the result of PASC Interpretation 1003.2-92 #43 submitted for
the ISO&nbsp;POSIX-2:1993 standard.</p>
<h5><a name="tag_01_09_03_07"></a>BRE Precedence</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_03_08"></a>BRE Expression Anchoring</h5>
<p>Often, the dollar sign is viewed as matching the ending &lt;newline&gt; in text files. This is not strictly true; the
&lt;newline&gt; is typically eliminated from the strings to be matched, and the dollar sign matches the terminating null
character.</p>
<p>The ability of <tt>'^'</tt> , <tt>'$'</tt> , and <tt>'*'</tt> to be non-special in certain circumstances may be confusing to
some programmers, but this situation was changed only in a minor way from historical practice to avoid breaking many historical
scripts. Some consideration was given to making the use of the anchoring characters undefined if not escaped and not at the
beginning or end of strings. This would cause a number of historical BREs, such as <tt>"2^10"</tt> , <tt>"$HOME"</tt> , and
<tt>"$1.35"</tt> , that relied on the characters being treated literally, to become invalid.</p>
<p>However, one relatively uncommon case was changed to allow an extension used on some implementations. Historically, the BREs
<tt>"^foo"</tt> and <tt>"\(^foo\)"</tt> did not match the same string, despite the general rule that subexpressions and entire BREs
match the same strings. To increase consensus, IEEE&nbsp;Std&nbsp;1003.1-2001 has allowed an extension on some implementations to
treat these two cases in the same way by declaring that anchoring <i>may</i> occur at the beginning or end of a subexpression.
Therefore, portable BREs that require a literal circumflex at the beginning or a dollar sign at the end of a subexpression must
escape them. Note that a BRE such as <tt>"a\(^bc\)"</tt> will either match <tt>"a^bc"</tt> or nothing on different systems under
the rules.</p>
<p>ERE anchoring has been different from BRE anchoring in all historical systems. An unescaped anchor character has never matched
its literal counterpart outside a bracket expression. Some implementations treated <tt>"foo$bar"</tt> as a valid expression that
never matched anything; others treated it as invalid. IEEE&nbsp;Std&nbsp;1003.1-2001 mandates the former, valid unmatched
behavior.</p>
<p>Some implementations have extended the BRE syntax to add alternation. For example, the subexpression <tt>"\(foo$\|bar\)"</tt>
would match either <tt>"foo"</tt> at the end of the string or <tt>"bar"</tt> anywhere. The extension is triggered by the use of the
undefined <tt>"\|"</tt> sequence. Because the BRE is undefined for portable scripts, the extending system is free to make other
assumptions, such that the <tt>'$'</tt> represents the end-of-line anchor in the middle of a subexpression. If it were not for the
extension, the <tt>'$'</tt> would match a literal dollar sign under the rules.</p>
<h4><a name="tag_01_09_04"></a>Extended Regular Expressions</h4>
<p>As with BREs, the standard developers decided to make the interpretation of escaped ordinary characters undefined.</p>
<p>The right parenthesis is not listed as an ERE special character because it is only special in the context of a preceding left
parenthesis. If found without a preceding left parenthesis, the right parenthesis has no special meaning.</p>
<p>The interval expression, <tt>"{m,n}"</tt> , has been added to EREs. Historically, the interval expression has only been
supported in some ERE implementations. The standard developers estimated that the addition of interval expressions to EREs would
not decrease consensus and would also make BREs more of a subset of EREs than in many historical implementations.</p>
<p>It was suggested that, in addition to interval expressions, back-references ( <tt>'\n'</tt> ) should also be added to EREs. This
was rejected by the standard developers as likely to decrease consensus.</p>
<p>In historical implementations, multiple duplication symbols are usually interpreted from left to right and treated as additive.
As an example, <tt>"a+*b"</tt> matches zero or more instances of <tt>'a'</tt> followed by a <tt>'b'</tt> . In
IEEE&nbsp;Std&nbsp;1003.1-2001, multiple duplication symbols are undefined; that is, they cannot be relied upon for conforming
applications. One reason for this is to provide some scope for future enhancements.</p>
<p>The precedence of operations differs between EREs and those in <a href="../utilities/lex.html"><i>lex</i></a>; in <a href=
"../utilities/lex.html"><i>lex</i></a>, for historical reasons, interval expressions have a lower precedence than
concatenation.</p>
<h5><a name="tag_01_09_04_01"></a>EREs Matching a Single Character or Collating Element</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_02"></a>ERE Ordinary Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_03"></a>ERE Special Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_04"></a>Periods in EREs</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_05"></a>ERE Bracket Expression</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_06"></a>EREs Matching Multiple Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_07"></a>ERE Alternation</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_08"></a>ERE Precedence</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_04_09"></a>ERE Expression Anchoring</h5>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_01_09_05"></a>Regular Expression Grammar</h4>
<p>The grammars are intended to represent the range of acceptable syntaxes available to conforming applications. There are
instances in the text where undefined constructs are described; as explained previously, these allow implementation extensions.
There is no intended requirement that an implementation extension must somehow fit into the grammars shown here.</p>
<p>The BRE grammar does not permit L_ANCHOR or R_ANCHOR inside <tt>"\("</tt> and <tt>"\)"</tt> (which implies that <tt>'^'</tt> and
<tt>'$'</tt> are ordinary characters). This reflects the semantic limits on the application, as noted in the Base Definitions
volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap09.html#tag_09_03_08">Section 9.3.8, BRE Expression
Anchoring</a>. Implementations are permitted to extend the language to interpret <tt>'^'</tt> and <tt>'$'</tt> as anchors in these
locations, and as such, conforming applications cannot use unescaped <tt>'^'</tt> and <tt>'$'</tt> in positions inside
<tt>"\("</tt> and <tt>"\)"</tt> that might be interpreted as anchors.</p>
<p>The ERE grammar does not permit several constructs that the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/xbd_chap09.html#tag_09_04_02">Section 9.4.2, ERE Ordinary Characters</a> and the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap09.html#tag_09_04_03">Section 9.4.3, ERE Special Characters</a>
specify as having undefined results:</p>
<ul>
<li>
<p>ORD_CHAR preceded by <tt>'\'</tt></p>
</li>
<li>
<p><i>ERE_dupl_symbol</i>(s) appearing first in an ERE, or immediately following <tt>'|'</tt> , <tt>'^'</tt> , or <tt>'('</tt></p>
</li>
<li>
<p><tt>'{'</tt> not part of a valid <i>ERE_dupl_symbol</i></p>
</li>
<li>
<p><tt>'|'</tt> appearing first or last in an ERE, or immediately following <tt>'|'</tt> or <tt>'('</tt> , or immediately preceding
<tt>')'</tt></p>
</li>
</ul>
<p>Implementations are permitted to extend the language to allow these. Conforming applications cannot use such constructs.</p>
<h5><a name="tag_01_09_05_01"></a>BRE/ERE Grammar Lexical Conventions</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_09_05_02"></a>RE and Bracket Expression Grammar</h5>
<p>The removal of the <i>Back_open_paren</i> <i>Back_close_paren</i> option from the <i>nondupl_RE</i> specification is the result
of PASC Interpretation 1003.2-92 #43 submitted for the ISO&nbsp;POSIX-2:1993 standard. Although the grammar required support for
null subexpressions, this section does not describe the meaning of, and historical practice did not support, this construct.</p>
<h5><a name="tag_01_09_05_03"></a>ERE Grammar</h5>
<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>

61
Ref-docs/POSIX/susv3/xrat/xbd_chap10.html Normal file
View File

@@ -0,0 +1,61 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_10"></a>Directory Structure and Devices</h3>
<h4><a name="tag_01_10_01"></a>Directory Structure and Files</h4>
<p>A description of the historical <b>/usr/tmp</b> was omitted, removing any concept of differences in emphasis between the
<b>/</b> and <b>/usr</b> directories. The descriptions of <b>/bin</b>, <b>/usr/bin</b>, <b>/lib</b>, and <b>/usr/lib</b> were
omitted because they are not useful for applications. In an early draft, a distinction was made between system and application
directory usage, but this was not found to be useful.</p>
<p>The directories <b>/</b> and <b>/dev</b> are included because the notion of a hierarchical directory structure is key to other
information presented elsewhere in IEEE&nbsp;Std&nbsp;1003.1-2001. In early drafts, it was argued that special devices and
temporary files could conceivably be handled without a directory structure on some implementations. For example, the system could
treat the characters <tt>"/tmp"</tt> as a special token that would store files using some non-POSIX file system structure. This
notion was rejected by the standard developers, who required that all the files in this section be implemented via POSIX file
systems.</p>
<p>The <b>/tmp</b> directory is retained in IEEE&nbsp;Std&nbsp;1003.1-2001 to accommodate historical applications that assume its
availability. Implementations are encouraged to provide suitable directory names in the environment variable <i>TMPDIR</i> and
applications are encouraged to use the contents of <i>TMPDIR</i> for creating temporary files.</p>
<p>The standard files <b>/dev/null</b> and <b>/dev/tty</b> are required to be both readable and writable to allow applications to
have the intended historical access to these files.</p>
<p>The standard file <b>/dev/console</b> has been added for alignment with the Single UNIX Specification.</p>
<h4><a name="tag_01_10_02"></a>Output Devices and Terminal Types</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>

358
Ref-docs/POSIX/susv3/xrat/xbd_chap11.html Normal file
View File

@@ -0,0 +1,358 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_11"></a>General Terminal Interface</h3>
<p>If the implementation does not support this interface on any device types, it should behave as if it were being used on a device
that is not a terminal device (in most cases <i>errno</i> will be set to [ENOTTY] on return from functions defined by this
interface). This is based on the fact that many applications are written to run both interactively and in some non-interactive
mode, and they adapt themselves at runtime. Requiring that they all be modified to test an environment variable to determine
whether they should try to adapt is unnecessary. On a system that provides no general terminal interface, providing all the entry
points as stubs that return [ENOTTY] (or an equivalent, as appropriate) has the same effect and requires no changes to the
application.</p>
<p>Although the needs of both interface implementors and application developers were addressed throughout
IEEE&nbsp;Std&nbsp;1003.1-2001, this section pays more attention to the needs of the latter. This is because, while many aspects of
the programming interface can be hidden from the user by the application developer, the terminal interface is usually a large part
of the user interface. Although to some extent the application developer can build missing features or work around inappropriate
ones, the difficulties of doing that are greater in the terminal interface than elsewhere. For example, efficiency prohibits the
average program from interpreting every character passing through it in order to simulate character erase, line kill, and so on.
These functions should usually be done by the operating system, possibly at the interrupt level.</p>
<p>The <i>tc*</i>() functions were introduced as a way of avoiding the problems inherent in the
traditional <a href="../functions/ioctl.html"><i>ioctl</i>()</a> function and in variants of it that were proposed. For example, <a
href="../functions/tcsetattr.html"><i>tcsetattr</i>()</a> is specified in place of the use of the TCSETA <a href=
"../functions/ioctl.html"><i>ioctl</i>()</a> command function. This allows specification of all the arguments in a manner
consistent with the ISO&nbsp;C standard unlike the varying third argument of <a href="../functions/ioctl.html"><i>ioctl</i>()</a>,
which is sometimes a pointer (to any of many different types) and sometimes an <b>int</b>.</p>
<p>The advantages of this new method include:</p>
<ul>
<li>
<p>It allows strict type checking.</p>
</li>
<li>
<p>The direction of transfer of control data is explicit.</p>
</li>
<li>
<p>Portable capabilities are clearly identified.</p>
</li>
<li>
<p>The need for a general interface routine is avoided.</p>
</li>
<li>
<p>Size of the argument is well-defined (there is only one type).</p>
</li>
</ul>
<p>The disadvantages include:</p>
<ul>
<li>
<p>No historical implementation used the new method.</p>
</li>
<li>
<p>There are many small routines instead of one general-purpose one.</p>
</li>
<li>
<p>The historical parallel with <a href="../functions/fcntl.html"><i>fcntl</i>()</a> is broken.</p>
</li>
</ul>
<p>The issue of modem control was excluded from IEEE&nbsp;Std&nbsp;1003.1-2001 on the grounds that:</p>
<ul>
<li>
<p>It was concerned with setting and control of hardware timers.</p>
</li>
<li>
<p>The appropriate timers and settings vary widely internationally.</p>
</li>
<li>
<p>Feedback from European computer manufacturers indicated that this facility was not consistent with European needs and that
specification of such a facility was not a requirement for portability.</p>
</li>
</ul>
<h4><a name="tag_01_11_01"></a>Interface Characteristics</h4>
<h5><a name="tag_01_11_01_01"></a>Opening a Terminal Device File</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_11_01_02"></a>Process Groups</h5>
<p>There is a potential race when the members of the foreground process group on a terminal leave that process group, either by
exit or by changing process groups. After the last process exits the process group, but before the foreground process group ID of
the terminal is changed (usually by a job control shell), it would be possible for a new process to be created with its process ID
equal to the terminal's foreground process group ID. That process might then become the process group leader and accidentally be
placed into the foreground on a terminal that was not necessarily its controlling terminal. As a result of this problem, the
controlling terminal is defined to not have a foreground process group during this time.</p>
<p>The cases where a controlling terminal has no foreground process group occur when all processes in the foreground process group
either terminate and are waited for or join other process groups via <a href="../functions/setpgid.html"><i>setpgid</i>()</a> or <a
href="../functions/setsid.html"><i>setsid</i>()</a>. If the process group leader terminates, this is the first case described; if
it leaves the process group via <a href="../functions/setpgid.html"><i>setpgid</i>()</a>, this is the second case described (a
process group leader cannot successfully call <a href="../functions/setsid.html"><i>setsid</i>()</a>). When one of those cases
causes a controlling terminal to have no foreground process group, it has two visible effects on applications. The first is the
value returned by <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>. The second (which occurs only in the case where the
process group leader terminates) is the sending of signals in response to special input characters. The intent of
IEEE&nbsp;Std&nbsp;1003.1-2001 is that no process group be wrongly identified as the foreground process group by <a href=
"../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a> or unintentionally receive signals because of placement into the
foreground.</p>
<p>In 4.3 BSD, the old process group ID continues to be used to identify the foreground process group and is returned by the
function equivalent to <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>. In that implementation it is possible for a
newly created process to be assigned the same value as a process ID and then form a new process group with the same value as a
process group ID. The result is that the new process group would receive signals from this terminal for no apparent reason, and
IEEE&nbsp;Std&nbsp;1003.1-2001 precludes this by forbidding a process group from entering the foreground in this way. It would be
more direct to place part of the requirement made by the last sentence under <a href="../functions/fork.html"><i>fork</i>()</a>,
but there is no convenient way for that section to refer to the value that <a href=
"../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a> returns, since in this case there is no process group and thus no process
group ID.</p>
<p>One possibility for a conforming implementation is to behave similarly to 4.3 BSD, but to prevent this reuse of the ID, probably
in the implementation of <a href="../functions/fork.html"><i>fork</i>()</a>, as long as it is in use by the terminal.</p>
<p>Another possibility is to recognize when the last process stops using the terminal's foreground process group ID, which is when
the process group lifetime ends, and to change the terminal's foreground process group ID to a reserved value that is never used as
a process ID or process group ID. (See the definition of <i>process group lifetime</i> in the definitions section.) The process ID
can then be reserved until the terminal has another foreground process group.</p>
<p>The 4.3 BSD implementation permits the leader (and only member) of the foreground process group to leave the process group by
calling the equivalent of <a href="../functions/setpgid.html"><i>setpgid</i>()</a> and to later return, expecting to return to the
foreground. There are no known application needs for this behavior, and IEEE&nbsp;Std&nbsp;1003.1-2001 neither requires nor forbids
it (except that it is forbidden for session leaders) by leaving it unspecified.</p>
<h5><a name="tag_01_11_01_03"></a>The Controlling Terminal</h5>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 does not specify a mechanism by which to allocate a controlling terminal. This is normally done
by a system utility (such as <i>getty</i>) and is considered an administrative feature outside the scope of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>Historical implementations allocate controlling terminals on certain <a href="../functions/open.html"><i>open</i>()</a> calls.
Since <a href="../functions/open.html"><i>open</i>()</a> is part of POSIX.1, its behavior had to be dealt with. The traditional
behavior is not required because it is not very straightforward or flexible for either implementations or applications. However,
because of its prevalence, it was not practical to disallow this behavior either. Thus, a mechanism was standardized to ensure
portable, predictable behavior in <a href="../functions/open.html"><i>open</i>()</a>.</p>
<p>Some historical implementations deallocate a controlling terminal on the last system-wide close. This behavior in neither
required nor prohibited. Even on implementations that do provide this behavior, applications generally cannot depend on it due to
its system-wide nature.</p>
<h5><a name="tag_01_11_01_04"></a>Terminal Access Control</h5>
<p>The access controls described in this section apply only to a process that is accessing its controlling terminal. A process
accessing a terminal that is not its controlling terminal is effectively treated the same as a member of the foreground process
group. While this may seem unintuitive, note that these controls are for the purpose of job control, not security, and job control
relates only to a process' controlling terminal. Normal file access permissions handle security.</p>
<p>If the process calling <a href="../functions/read.html"><i>read</i>()</a> or <a href=
"../functions/write.html"><i>write</i>()</a> is in a background process group that is orphaned, it is not desirable to stop the
process group, as it is no longer under the control of a job control shell that could put it into the foreground again.
Accordingly, calls to <a href="../functions/read.html"><i>read</i>()</a> or <a href="../functions/write.html"><i>write</i>()</a>
functions by such processes receive an immediate error return. This is different from 4.2 BSD, which kills orphaned processes that
receive terminal stop signals.</p>
<p>The foreground/background/orphaned process group check performed by the terminal driver must be repeatedly performed until the
calling process moves into the foreground or until the process group of the calling process becomes orphaned. That is, when the
terminal driver determines that the calling process is in the background and should receive a job control signal, it sends the
appropriate signal (SIGTTIN or SIGTTOU) to every process in the process group of the calling process and then it allows the calling
process to immediately receive the signal. The latter is typically performed by blocking the process so that the signal is
immediately noticed. Note, however, that after the process finishes receiving the signal and control is returned to the driver, the
terminal driver must re-execute the foreground/background/orphaned process group check. The process may still be in the background,
either because it was continued in the background by a job control shell, or because it caught the signal and did nothing.</p>
<p>The terminal driver repeatedly performs the foreground/background/orphaned process group checks whenever a process is about to
access the terminal. In the case of <a href="../functions/write.html"><i>write</i>()</a> or the control
<i>tc*</i>() functions, the check is performed at the entry of the function. In the case of <a href=
"../functions/read.html"><i>read</i>()</a>, the check is performed not only at the entry of the function, but also after blocking
the process to wait for input characters (if necessary). That is, once the driver has determined that the process calling the <a
href="../functions/read.html"><i>read</i>()</a> function is in the foreground, it attempts to retrieve characters from the input
queue. If the queue is empty, it blocks the process waiting for characters. When characters are available and control is returned
to the driver, the terminal driver must return to the repeated foreground/background/orphaned process group check again. The
process may have moved from the foreground to the background while it was blocked waiting for input characters.</p>
<h5><a name="tag_01_11_01_05"></a>Input Processing and Reading Data</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_11_01_06"></a>Canonical Mode Input Processing</h5>
<p>The term &quot;character&quot; is intended here. ERASE should erase the last character, not the last byte. In the case of multi-byte
characters, these two may be different.</p>
<p>4.3 BSD has a WERASE character that erases the last &quot;word&quot; typed (but not any preceding &lt;blank&gt;s or &lt;tab&gt;s). A
word is defined as a sequence of non- &lt;blank&gt;s, with &lt;tab&gt;s counted as &lt;blank&gt;s. Like ERASE, WERASE does not
erase beyond the beginning of the line. This WERASE feature has not been specified in POSIX.1 because it is difficult to define in
the international environment. It is only useful for languages where words are delimited by &lt;blank&gt;s. In some ideographic
languages, such as Japanese and Chinese, words are not delimited at all. The WERASE character should presumably go back to the
beginning of a sentence in those cases; practically, this means it would not be used much for those languages.</p>
<p>It should be noted that there is a possible inherent deadlock if the application and implementation conflict on the value of
{MAX_CANON}. With ICANON set (if IXOFF is enabled) and more than {MAX_CANON} characters transmitted without a &lt;linefeed&gt;,
transmission will be stopped, the &lt;linefeed&gt; (or &lt;carriage-return&gt; when ICRLF is set) will never arrive, and the <a
href="../functions/read.html"><i>read</i>()</a> will never be satisfied.</p>
<p>An application should not set IXOFF if it is using canonical mode unless it knows that (even in the face of a transmission
error) the conditions described previously cannot be met or unless it is prepared to deal with the possible deadlock in some other
way, such as timeouts.</p>
<p>It should also be noted that this can be made to happen in non-canonical mode if the trigger value for sending IXOFF is less
than VMIN and VTIME is zero.</p>
<h5><a name="tag_01_11_01_07"></a>Non-Canonical Mode Input Processing</h5>
<p>Some points to note about MIN and TIME:</p>
<ol>
<li>
<p>The interactions of MIN and TIME are not symmetric. For example, when MIN&gt;0 and TIME=0, TIME has no effect. However, in the
opposite case where MIN=0 and TIME&gt;0, both MIN and TIME play a role in that MIN is satisfied with the receipt of a single
character.</p>
</li>
<li>
<p>Also note that in case A (MIN&gt;0, TIME&gt;0), TIME represents an inter-character timer, while in case C (MIN=0, TIME&gt;0),
TIME represents a read timer.</p>
</li>
</ol>
<p>These two points highlight the dual purpose of the MIN/TIME feature. Cases A and B, where MIN&gt;0, exist to handle burst-mode
activity (for example, file transfer programs) where a program would like to process at least MIN characters at a time. In case A,
the inter-character timer is activated by a user as a safety measure; in case B, it is turned off.</p>
<p>Cases C and D exist to handle single-character timed transfers. These cases are readily adaptable to screen-based applications
that need to know if a character is present in the input queue before refreshing the screen. In case C, the read is timed; in case
D, it is not.</p>
<p>Another important note is that MIN is always just a minimum. It does not denote a record length. That is, if a program does a
read of 20 bytes, MIN is 10, and 25 characters are present, 20 characters are returned to the user. In the special case of MIN=0,
this still applies: if more than one character is available, they all will be returned immediately.</p>
<h5><a name="tag_01_11_01_08"></a>Writing Data and Output Processing</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_11_01_09"></a>Special Characters</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_11_01_10"></a>Modem Disconnect</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_01_11_01_11"></a>Closing a Terminal Device File</h5>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 does not specify that a <a href="../functions/close.html"><i>close</i>()</a> on a terminal device
file include the equivalent of a call to <i>tcflow</i>( <i>fd</i>,TCOON).</p>
<p>An implementation that discards output at the time <a href="../functions/close.html"><i>close</i>()</a> is called after
reporting the return value to the <a href="../functions/write.html"><i>write</i>()</a> call that data was written does not conform
with IEEE&nbsp;Std&nbsp;1003.1-2001. An application has functions such as <a href="../functions/tcdrain.html"><i>tcdrain</i>()</a>,
<a href="../functions/tcflush.html"><i>tcflush</i>()</a>, and <a href="../functions/tcflow.html"><i>tcflow</i>()</a> available to
obtain the detailed behavior it requires with respect to flushing of output.</p>
<p>At the time of the last close on a terminal device, an application relinquishes any ability to exert flow control via <a href=
"../functions/tcflow.html"><i>tcflow</i>()</a>.</p>
<h4><a name="tag_01_11_02"></a>Parameters that Can be Set</h4>
<h5><a name="tag_01_11_02_01"></a>The termios Structure</h5>
<p>This structure is part of an interface that, in general, retains the historic grouping of flags. Although a more optimal
structure for implementations may be possible, the degree of change to applications would be significantly larger.</p>
<h5><a name="tag_01_11_02_02"></a>Input Modes</h5>
<p>Some historical implementations treated a long break as multiple events, as many as one per character time. The wording in
POSIX.1 explicitly prohibits this.</p>
<p>Although the ISTRIP flag is normally superfluous with today's terminal hardware and software, it is historically supported.
Therefore, applications may be using ISTRIP, and there is no technical problem with supporting this flag. Also, applications may
wish to receive only 7-bit input bytes and may not be connected directly to the hardware terminal device (for example, when a
connection traverses a network).</p>
<p>Also, there is no requirement in general that the terminal device ensures that high-order bits beyond the specified character
size are cleared. ISTRIP provides this function for 7-bit characters, which are common.</p>
<p>In dealing with multi-byte characters, the consequences of a parity error in such a character, or in an escape sequence
affecting the current character set, are beyond the scope of POSIX.1 and are best dealt with by the application processing the
multi-byte characters.</p>
<h5><a name="tag_01_11_02_03"></a>Output Modes</h5>
<p>POSIX.1 does not describe postprocessing of output to a terminal or detailed control of that from a conforming application.
(That is, translation of &lt;newline&gt; to &lt;carriage-return&gt; followed by &lt;linefeed&gt; or &lt;tab&gt; processing.) There
is nothing that a conforming application should do to its output for a terminal because that would require knowledge of the
operation of the terminal. It is the responsibility of the operating system to provide postprocessing appropriate to the output
device, whether it is a terminal or some other type of device.</p>
<p>Extensions to POSIX.1 to control the type of postprocessing already exist and are expected to continue into the future. The
control of these features is primarily to adjust the interface between the system and the terminal device so the output appears on
the display correctly. This should be set up before use by any application.</p>
<p>In general, both the input and output modes should not be set absolutely, but rather modified from the inherited state.</p>
<h5><a name="tag_01_11_02_04"></a>Control Modes</h5>
<p>This section could be misread that the symbol &quot;CSIZE&quot; is a title in the <b>termios</b> <i>c_cflag</i> field. Although it does
serve that function, it is also a required symbol, as a literal reading of POSIX.1 (and the caveats about typography) would
indicate.</p>
<h5><a name="tag_01_11_02_05"></a>Local Modes</h5>
<p>Non-canonical mode is provided to allow fast bursts of input to be read efficiently while still allowing single-character
input.</p>
<p>The ECHONL function historically has been in many implementations. Since there seems to be no technical problem with supporting
ECHONL, it is included in POSIX.1 to increase consensus.</p>
<p>The alternate behavior possible when ECHOK or ECHOE are specified with ICANON is permitted as a compromise depending on what the
actual terminal hardware can do. Erasing characters and lines is preferred, but is not always possible.</p>
<h5><a name="tag_01_11_02_06"></a>Special Control Characters</h5>
<p>Permitting VMIN and VTIME to overlap with VEOF and VEOL was a compromise for historical implementations. Only when
backwards-compatibility of object code is a serious concern to an implementor should an implementation continue this practice.
Correct applications that work with the overlap (at the source level) should also work if it is not present, but not the
reverse.</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>

310
Ref-docs/POSIX/susv3/xrat/xbd_chap12.html Normal file
View File

@@ -0,0 +1,310 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_12"></a>Utility Conventions</h3>
<h4><a name="tag_01_12_01"></a>Utility Argument Syntax</h4>
<p>The standard developers considered that recent trends toward diluting the SYNOPSIS sections of historical reference pages to the
equivalent of:</p>
<blockquote>
<pre>
<tt>command</tt> <b>[</b><i>options</i><b>][</b><i>operands</i><b>]</b>
</pre>
</blockquote>
<p>were a disservice to the reader. Therefore, considerable effort was placed into rigorous definitions of all the command line
arguments and their interrelationships. The relationships depicted in the synopses are normative parts of
IEEE&nbsp;Std&nbsp;1003.1-2001; this information is sometimes repeated in textual form, but that is only for clarity within
context.</p>
<p>The use of &quot;undefined&quot; for conflicting argument usage and for repeated usage of the same option is meant to prevent conforming
applications from using conflicting arguments or repeated options unless specifically allowed (as is the case with <a href=
"../utilities/ls.html"><i>ls</i></a>, which allows simultaneous, repeated use of the <b>-C</b>, <b>-l</b>, and <b>-1</b> options).
Many historical implementations will tolerate this usage, choosing either the first or the last applicable argument. This tolerance
can continue, but conforming applications cannot rely upon it. (Other implementations may choose to print usage messages
instead.)</p>
<p>The use of &quot;undefined&quot; for conflicting argument usage also allows an implementation to make reasonable extensions to utilities
where the implementor considers mutually-exclusive options according to IEEE&nbsp;Std&nbsp;1003.1-2001 to have a sensible meaning
and result.</p>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 does not define the result of a command when an option-argument or operand is not followed by
ellipses and the application specifies more than one of that option-argument or operand. This allows an implementation to define
valid (although non-standard) behavior for the utility when more than one such option or operand is specified.</p>
<p>The following table summarizes the requirements for option-arguments:</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="center">
<p class="tent">&nbsp;</p>
</th>
<th colspan="3" align="center">
<p class="tent"><b>SYNOPSIS Shows:</b></p>
</th>
</tr>
<tr valign="top">
<th align="center">
<p class="tent">&nbsp;</p>
</th>
<th colspan="3" align="center">
<p class="tent"><b>_</b></p>
</th>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">-a <i>arg</i></p>
</td>
<td align="center">
<p class="tent">-b<i>arg</i></p>
</td>
<td align="center">
<p class="tent">-c[<i>arg</i>]</p>
</td>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">Conforming</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">application uses:</p>
</td>
<td align="center">
<p class="tent">-a <i>arg</i></p>
</td>
<td align="center">
<p class="tent">-b<i>arg</i></p>
</td>
<td align="center">
<p class="tent">-c<i>arg</i> or <tt>-c</tt></p>
</td>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">System supports:</p>
</td>
<td align="center">
<p class="tent">-a <i>arg</i> and <tt>-a</tt><i>arg</i></p>
</td>
<td align="center">
<p class="tent">-b <i>arg</i> and <i>-barg</i></p>
</td>
<td align="center">
<p class="tent">-carg and <tt>-c</tt></p>
</td>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">Non-conforming</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
</tr>
<tr valign="top">
<td align="right">
<p class="tent">applications may use:</p>
</td>
<td align="center">
<p class="tent">-a<i>arg</i></p>
</td>
<td align="center">
<p class="tent">-b <i>arg</i></p>
</td>
<td align="center">
<p class="tent">N/A</p>
</td>
</tr>
</table>
</center>
<p>Allowing &lt;blank&gt;s after an option (that is, placing an option and its option-argument into separate argument strings) when
IEEE&nbsp;Std&nbsp;1003.1-2001 does not require it encourages portability of users, while still preserving backwards-compatibility
of scripts. Inserting &lt;blank&gt;s between the option and the option-argument is preferred; however, historical usage has not
been consistent in this area; therefore, &lt;blank&gt;s are required to be handled by all implementations, but implementations are
also allowed to handle the historical syntax. Another justification for selecting the multiple-argument method was that the
single-argument case is inherently ambiguous when the option-argument can legitimately be a null string.</p>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 explicitly states that digits are permitted as operands and option-arguments. The lower and upper
bounds for the values of the numbers used for operands and option-arguments were derived from the ISO&nbsp;C standard values for
{LONG_MIN} and {LONG_MAX}. The requirement on the standard utilities is that numbers in the specified range do not cause a syntax
error, although the specification of a number need not be semantically correct for a particular operand or option-argument of a
utility. For example, the specification of:</p>
<blockquote>
<pre>
dd obs=3000000000
</pre>
</blockquote>
<p>would yield undefined behavior for the application and could be a syntax error because the number 3000000000 is outside of the
range -2147483647 to +2147483647. On the other hand:</p>
<blockquote>
<pre>
<tt>dd obs=2000000000
</tt>
</pre>
</blockquote>
<p>may cause some error, such as &quot;blocksize too large&quot;, rather than a syntax error.</p>
<h4><a name="tag_01_12_02"></a>Utility Syntax Guidelines</h4>
<p>This section is based on the rules listed in the SVID. It was included for two reasons:</p>
<ol>
<li>
<p>The individual utility descriptions in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../utilities/xcu_chap04.html">Chapter 4, Utilities</a> needed a set of common (although not universal) actions on which they could
anchor their descriptions of option and operand syntax. Most of the standard utilities actually do use these guidelines, and many
of their historical implementations use the <a href="../functions/getopt.html"><i>getopt</i>()</a> function for their parsing.
Therefore, it was simpler to cite the rules and merely identify exceptions.</p>
</li>
<li>
<p>Writers of conforming applications need suggested guidelines if the POSIX community is to avoid the chaos of historical UNIX
system command syntax.</p>
</li>
</ol>
<p>It is recommended that all <i>future</i> utilities and applications use these guidelines to enhance &quot;user portability&quot;. The
fact that some historical utilities could not be changed (to avoid breaking historical applications) should not deter this future
goal.</p>
<p>The voluntary nature of the guidelines is highlighted by repeated uses of the word <i>should</i> throughout. This usage should
not be misinterpreted to imply that utilities that claim conformance in their OPTIONS sections do not always conform.</p>
<p>Guidelines 1 and 2 are offered as guidance for locales using Latin alphabets. No recommendations are made by
IEEE&nbsp;Std&nbsp;1003.1-2001 concerning utility naming in other locales.</p>
<p>In the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_09_01">Section
2.9.1, Simple Commands</a>, it is further stated that a command used in the Shell Command Language cannot be named with a trailing
colon.</p>
<p>Guideline 3 was changed to allow alphanumeric characters (letters and digits) from the character set to allow compatibility with
historical usage. Historical practice allows the use of digits wherever practical, and there are no portability issues that would
prohibit the use of digits. In fact, from an internationalization viewpoint, digits (being non-language-dependent) are preferable
over letters (a <b>-2</b> is intuitively self-explanatory to any user, while in the <b>-f</b> <i>filename</i> the letter
<tt>'f'</tt> is a mnemonic aid only to speakers of Latin-based languages where &quot;filename&quot; happens to translate to a word that
begins with <tt>'f'</tt> . Since guideline 3 still retains the word &quot;single&quot;, multi-digit options are not allowed. Instances of
historical utilities that used them have been marked obsolescent, with the numbers being changed from option names to
option-arguments.</p>
<p>It was difficult to achieve a satisfactory solution to the problem of name space in option characters. When the standard
developers desired to extend the historical <i>cc</i> utility to accept ISO&nbsp;C standard programs, they found that all of the
portable alphabet was already in use by various vendors. Thus, they had to devise a new name, <i>c89</i> (now superseded by <a
href="../utilities/c99.html"><i>c99</i></a>), rather than something like <i>cc</i> <b>-X</b>. There were suggestions that
implementors be restricted to providing extensions through various means (such as using a plus sign as the option delimiter or
using option characters outside the alphanumeric set) that would reserve all of the remaining alphanumeric characters for future
POSIX standards. These approaches were resisted because they lacked the historical style of UNIX systems. Furthermore, if a
vendor-provided option should become commonly used in the industry, it would be a candidate for standardization. It would be
desirable to standardize such a feature using historical practice for the syntax (the semantics can be standardized with any
syntax). This would not be possible if the syntax was one reserved for the vendor. However, since the standardization process may
lead to minor changes in the semantics, it may prove to be better for a vendor to use a syntax that will not be affected by
standardization.</p>
<p>Guideline 8 includes the concept of comma-separated lists in a single argument. It is up to the utility to parse such a list
itself because <a href="../functions/getopt.html"><i>getopt</i>()</a> just returns the single string. This situation was retained
so that certain historical utilities would not violate the guidelines. Applications preparing for international use should be aware
of an occasional problem with comma-separated lists: in some locales, the comma is used as the radix character. Thus, if an
application is preparing operands for a utility that expects a comma-separated list, it should avoid generating non-integer values
through one of the means that is influenced by setting the <i>LC_NUMERIC</i> variable (such as <a href=
"../utilities/awk.html"><i>awk</i></a>, <a href="../utilities/bc.html"><i>bc</i></a>, <a href=
"../utilities/printf.html"><i>printf</i></a>, or <a href="../functions/printf.html"><i>printf</i>()</a>).</p>
<p>Applications calling any utility with a first operand starting with <tt>'-'</tt> should usually specify <b>--</b>, as indicated
by Guideline 10, to mark the end of the options. This is true even if the SYNOPSIS in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 does not specify any options; implementations may provide options as extensions to the Shell and
Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001. The standard utilities that do not support Guideline 10 indicate that fact in
the OPTIONS section of the utility description.</p>
<p>Guideline 11 was modified to clarify that the order of different options should not matter relative to one another. However, the
order of repeated options that also have option-arguments may be significant; therefore, such options are required to be
interpreted in the order that they are specified. The <a href="../utilities/make.html"><i>make</i></a> utility is an instance of a
historical utility that uses repeated options in which the order is significant. Multiple files are specified by giving multiple
instances of the <b>-f</b> option; for example:</p>
<blockquote>
<pre>
<tt>make -f common_header -f specific_rules target
</tt>
</pre>
</blockquote>
<p>Guideline 13 does not imply that all of the standard utilities automatically accept the operand <tt>'-'</tt> to mean standard
input or output, nor does it specify the actions of the utility upon encountering multiple <tt>'-'</tt> operands. It simply says
that, by default, <tt>'-'</tt> operands are not used for other purposes in the file reading or writing (but not when using <a href=
"../functions/stat.html"><i>stat</i>()</a>, <a href="../functions/unlink.html"><i>unlink</i>()</a>, <a href=
"../utilities/touch.html"><i>touch</i></a>, and so on) utilities. All information concerning actual treatment of the <tt>'-'</tt>
operand is found in the individual utility sections.</p>
<p>An area of concern was that as implementations mature, implementation-defined utilities and implementation-defined utility
options will result. The idea was expressed that there needed to be a standard way, say an environment variable or some such
mechanism, to identify implementation-defined utilities separately from standard utilities that may have the same name. It was
decided that there already exist several ways of dealing with this situation and that it is outside of the scope to attempt to
standardize in the area of non-standard items. A method that exists on some historical implementations is the use of the so-called
<b>/local/bin</b> or <b>/usr/local/bin</b> directory to separate local or additional copies or versions of utilities. Another
method that is also used is to isolate utilities into completely separate domains. Still another method to ensure that the desired
utility is being used is to request the utility by its full pathname. There are many approaches to this situation; the examples
given above serve to illustrate that there is more than one.</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>

51
Ref-docs/POSIX/susv3/xrat/xbd_chap13.html Normal file
View File

@@ -0,0 +1,51 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_01_13"></a>Headers</h3>
<h4><a name="tag_01_13_01"></a>Format of Entries</h4>
<p>Each header reference page has a common layout of sections describing the interface. This layout is similar to the manual page
or &quot;man&quot; page format shipped with most UNIX systems, and each header has sections describing the SYNOPSIS and DESCRIPTION. These
are the two sections that relate to conformance.</p>
<p>Additional sections are informative, and add considerable information for the application developer. APPLICATION USAGE sections
provide additional caveats, issues, and recommendations to the developer. RATIONALE sections give additional information on the
decisions made in defining the interface.</p>
<p>FUTURE DIRECTIONS sections act as pointers to related work that may impact the interface in the future, and often cautions the
developer to architect the code to account for a change in this area. Note that a future directions statement should not be taken
as a commitment to adopt a feature or interface in the future.</p>
<p>The CHANGE HISTORY section describes when the interface was introduced, and how it has changed.</p>
<p>Option labels and margin markings in the page can be useful in guiding the application developer.</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>

901
Ref-docs/POSIX/susv3/xrat/xcu_chap01.html Normal file
View File

@@ -0,0 +1,901 @@
<!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 Shell and Utilities</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 &copy; 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
<!--header end-->
<hr size="2" noshade>
<h2><a name="tag_02"></a>Rationale for Shell and Utilities</h2>
<h3><a name="tag_02_01"></a>Introduction</h3>
<h4><a name="tag_02_01_01"></a>Scope</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_01"><i>Scope</i></a> .</p>
<h4><a name="tag_02_01_02"></a>Conformance</h4>
<p>Refer to <a href="xbd_chap02.html#tag_01_02"><i>Conformance</i></a> .</p>
<h4><a name="tag_02_01_03"></a>Normative References</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_02_01_04"></a>Change History</h4>
<p>The change history is provided as an informative section, to track changes from previous issues of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>The following sections describe changes made to the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 since Issue 5
of the base document. The CHANGE HISTORY section for each utility describes technical changes made to that utility from Issue 5.
Changes between earlier issues of the base document and Issue 5 are not included.</p>
<p>The change history between Issue 5 and Issue 6 also lists the changes since the ISO&nbsp;POSIX-2:1993 standard.</p>
<h5><a name="tag_02_01_04_01"></a>Changes from Issue 5 to Issue 6 (IEEE&nbsp;Std&nbsp;1003.1-2001)</h5>
<p>The following list summarizes the major changes that were made in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 from Issue 5 to Issue 6:</p>
<ul>
<li>
<p>This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is extensively revised so that it can be both an IEEE POSIX Standard and an Open
Group Technical Standard.</p>
</li>
<li>
<p>The terminology has been reworked to meet the style requirements.</p>
</li>
<li>
<p>Shading notation and margin codes are introduced for identification of options within the volume.</p>
</li>
<li>
<p>This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is updated to mandate support of FIPS 151-2. The following changes were made:</p>
<ul>
<li>
<p>Support is mandated for the capabilities associated with the following symbolic constants:</p>
<blockquote>
<pre>
_POSIX_CHOWN_RESTRICTED
_POSIX_JOB_CONTROL
_POSIX_SAVED_IDS
</pre>
</blockquote>
</li>
<li>
<p>In the environment for the login shell, the environment variables <i>LOGNAME</i> and <i>HOME</i> shall be defined and have the
properties described in the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/xbd_chap07.html">Chapter 7, Locale</a>.</p>
</li>
</ul>
</li>
<li>
<p>This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is updated to align with some features of the Single UNIX Specification.</p>
</li>
<li>
<p>A new section on Utility Limits is added.</p>
</li>
<li>
<p>A section on the Relationships to Other Documents is added.</p>
</li>
<li>
<p>Concepts and definitions have been moved to a separate volume.</p>
</li>
<li>
<p>A RATIONALE section is added to each reference page.</p>
</li>
<li>
<p>The <a href="../utilities/c99.html"><i>c99</i></a> utility is added as a replacement for <i>c89</i>, which is withdrawn in this
issue.</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.2d-1994 is incorporated, adding the <a href="../utilities/qalter.html"><i>qalter</i></a>, <a href=
"../utilities/qdel.html"><i>qdel</i></a>, <a href="../utilities/qhold.html"><i>qhold</i></a>, <a href=
"../utilities/qmove.html"><i>qmove</i></a>, <a href="../utilities/qmsg.html"><i>qmsg</i></a>, <a href=
"../utilities/qrerun.html"><i>qrerun</i></a>, <a href="../utilities/qrls.html"><i>qrls</i></a>, <a href=
"../utilities/qselect.html"><i>qselect</i></a>, <a href="../utilities/qsig.html"><i>qsig</i></a>, <a href=
"../utilities/qstat.html"><i>qstat</i></a>, and <a href="../utilities/qsub.html"><i>qsub</i></a> utilities.</p>
</li>
<li>
<p>IEEE&nbsp;P1003.2b draft standard is incorporated, making extensive updates and adding the <a href=
"../utilities/iconv.html"><i>iconv</i></a> utility.</p>
</li>
<li>
<p>IEEE PASC Interpretations are applied.</p>
</li>
<li>
<p>The Open Group's corrigenda and resolutions are applied.</p>
</li>
</ul>
<h5><a name="tag_02_01_04_02"></a>New Features in Issue 6</h5>
<p>The following table lists the new utilities introduced since the ISO&nbsp;POSIX-2:1993 standard (as modified by
IEEE&nbsp;Std&nbsp;1003.2d-1994). Apart from the <a href="../utilities/c99.html"><i>c99</i></a> and <a href=
"../utilities/iconv.html"><i>iconv</i></a> utilities, these are all part of the XSI extension.</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="8" align="center">
<p class="tent"><b>New Utilities in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../utilities/admin.html"><i>admin</i></a><br>
<a href="../utilities/c99.html"><i>c99</i></a><br>
<a href="../utilities/cal.html"><i>cal</i></a><br>
<a href="../utilities/cflow.html"><i>cflow</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/compress.html"><i>compress</i></a><br>
<a href="../utilities/cxref.html"><i>cxref</i></a><br>
<a href="../utilities/delta.html"><i>delta</i></a><br>
<a href="../utilities/fuser.html"><i>fuser</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/gencat.html"><i>gencat</i></a><br>
<a href="../utilities/get.html"><i>get</i></a><br>
<a href="../utilities/hash.html"><i>hash</i></a><br>
<a href="../utilities/iconv.html"><i>iconv</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/ipcrm.html"><i>ipcrm</i></a><br>
<a href="../utilities/ipcs.html"><i>ipcs</i></a><br>
<a href="../utilities/link.html"><i>link</i></a><br>
<a href="../utilities/m4.html"><i>m4</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/nl.html"><i>nl</i></a><br>
<a href="../utilities/prs.html"><i>prs</i></a><br>
<a href="../utilities/sact.html"><i>sact</i></a><br>
<a href="../utilities/sccs.html"><i>sccs</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/tsort.html"><i>tsort</i></a><br>
<a href="../utilities/ulimit.html"><i>ulimit</i></a><br>
<a href="../utilities/uncompress.html"><i>uncompress</i></a><br>
<a href="../utilities/unget.html"><i>unget</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/unlink.html"><i>unlink</i></a><br>
<a href="../utilities/uucp.html"><i>uucp</i></a><br>
<a href="../utilities/uustat.html"><i>uustat</i></a><br>
<a href="../utilities/uux.html"><i>uux</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../utilities/val.html"><i>val</i></a><br>
<a href="../utilities/what.html"><i>what</i></a><br>
<a href="../utilities/zcat.html"><i>zcat</i></a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<h4><a name="tag_02_01_05"></a>Terminology</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_04"><i>Terminology</i></a> .</p>
<h4><a name="tag_02_01_06"></a>Definitions</h4>
<p>Refer to <a href="xbd_chap03.html#tag_01_03"><i>Definitions</i></a> .</p>
<h4><a name="tag_02_01_07"></a>Relationship to Other Documents</h4>
<h5><a name="tag_02_01_07_01"></a>System Interfaces</h5>
<p>It has been pointed out that the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 assumes that a great deal of
functionality from the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is present, but never states exactly how much
(and strictly does not need to since both are mandated on a conforming system). This section is an attempt to clarify the
assumptions.</p>
<h5><a name="tag_02_01_07_02"></a>File Removal</h5>
<p>This is intended to be a summary of the <a href="../functions/unlink.html"><i>unlink</i>()</a> and <a href=
"../functions/rmdir.html"><i>rmdir</i>()</a> requirements. Note that it is possible using the <a href=
"../functions/unlink.html"><i>unlink</i>()</a> function for item 4. to occur.</p>
<h5><a name="tag_02_01_07_03"></a>Concepts Derived from the ISO C Standard</h5>
<p>This section was introduced to address the issue that there was insufficient detail presented by such utilities as <a href=
"../utilities/awk.html"><i>awk</i></a> or <a href="../utilities/sh.html"><i>sh</i></a> about their procedural control statements
and their methods of performing arithmetic functions.</p>
<p>The ISO&nbsp;C standard was selected as a model because most historical implementations of the standard utilities were written
in C. Thus, it was more likely that they would act in the desired manner without modification.</p>
<p>Using the ISO&nbsp;C standard is primarily a notational convenience so that the many procedural languages in the Shell and
Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 would not have to be rigorously described in every aspect. Its selection does
not require that the standard utilities be written in Standard C; they could be written in Common Usage C, Ada, Pascal, assembler
language, or anything else.</p>
<p>The sizes of the various numeric values refer to C-language data types that are allowed to be different sizes by the ISO&nbsp;C
standard. Thus, like a C-language application, a shell application cannot rely on their exact size. However, it can rely on their
minimum sizes expressed in the ISO&nbsp;C standard, such as {LONG_MAX} for a <b>long</b> type.</p>
<p>The behavior on overflow is undefined for ISO&nbsp;C standard arithmetic. Therefore, the standard utilities can use &quot;bignum''
representation for integers so that there is no fixed maximum unless otherwise stated in the utility description. Similarly,
standard utilities can use infinite-precision representations for floating-point arithmetic, as long as these representations
exceed the ISO&nbsp;C standard requirements.</p>
<p>This section addresses only the issue of semantics; it is not intended to specify syntax. For example, the ISO&nbsp;C standard
requires that 0L be recognized as an integer constant equal to zero, but utilities such as <a href=
"../utilities/awk.html"><i>awk</i></a> and <a href="../utilities/sh.html"><i>sh</i></a> are not required to recognize 0L (though
they are allowed to, as an extension).</p>
<p>The ISO&nbsp;C standard requires that a C compiler must issue a diagnostic for constants that are too large to represent. Most
standard utilities are not required to issue these diagnostics; for example, the command:</p>
<blockquote>
<pre>
<tt>diff -C 2147483648 file1 file2
</tt>
</pre>
</blockquote>
<p>has undefined behavior, and the <a href="../utilities/diff.html"><i>diff</i></a> utility is not required to issue a diagnostic
even if the number 2147483648 cannot be represented.</p>
<h4><a name="tag_02_01_08"></a>Portability</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_18"><i>Portability</i></a> .</p>
<h5><a name="tag_02_01_08_01"></a>Codes</h5>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_18_01"><i>Codes</i></a> .</p>
<h4><a name="tag_02_01_09"></a>Utility Limits</h4>
<p>This section grew out of an idea that originated with the original POSIX.1, in the tables of system limits for the <a href=
"../functions/sysconf.html"><i>sysconf</i>()</a> and <a href="../functions/pathconf.html"><i>pathconf</i>()</a> functions. The idea
being that a conforming application can be written to use the most restrictive values that a minimal system can provide, but it
should not have to. The values provided represent compromises so that some vendors can use historically limited versions of UNIX
system utilities. They are the highest values that a strictly conforming application can assume, given no other information.</p>
<p>However, by using the <a href="../utilities/getconf.html"><i>getconf</i></a> utility or the <a href=
"../functions/sysconf.html"><i>sysconf</i>()</a> function, the elegant application can be tailored to more liberal values on some
of the specific instances of specific implementations.</p>
<p>There is no explicitly stated requirement that an implementation provide finite limits for any of these numeric values; the
implementation is free to provide essentially unbounded capabilities (where it makes sense), stopping only at reasonable points
such as {ULONG_MAX} (from the ISO&nbsp;C standard). Therefore, applications desiring to tailor themselves to the values on a
particular implementation need to be ready for possibly huge values; it may not be a good idea to allocate blindly a buffer for an
input line based on the value of {LINE_MAX}, for instance. However, unlike the System Interfaces volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, there is no set of limits that return a special indication meaning &quot;unbounded&quot;. The
implementation should always return an actual number, even if the number is very large.</p>
<p>The statement:</p>
<blockquote>
<pre>
&quot;It is not guaranteed that the application ...''
</pre>
</blockquote>
<p>is an indication that many of these limits are designed to ensure that implementors design their utilities without arbitrary
constraints related to unimaginative programming. There are certainly conditions under which combinations of options can cause
failures that would not render an implementation non-conforming. For example, {EXPR_NEST_MAX} and {ARG_MAX} could collide when
expressions are large; combinations of {BC_SCALE_MAX} and {BC_DIM_MAX} could exceed virtual memory.</p>
<p>In the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, the notion of a limit being guaranteed for the process
lifetime, as it is in the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001, is not as useful to a shell script. The <a
href="../utilities/getconf.html"><i>getconf</i></a> utility is probably a process itself, so the guarantee would be without value.
Therefore, the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 requires the guarantee to be for the session lifetime.
This will mean that many vendors will either return very conservative values or possibly implement <a href=
"../utilities/getconf.html"><i>getconf</i></a> as a built-in.</p>
<p>It may seem confusing to have limits that apply only to a single utility grouped into one global section. However, the
alternative, which would be to disperse them out into their utility description sections, would cause great difficulty when <a
href="../functions/sysconf.html"><i>sysconf</i>()</a> and <a href="../utilities/getconf.html"><i>getconf</i></a> were described.
Therefore, the standard developers chose the global approach.</p>
<p>Each language binding could provide symbol names that are slightly different from those shown here. For example, the C-Language
Binding option adds a leading underscore to the symbols as a prefix.</p>
<p>The following comments describe selection criteria for the symbols and their values:</p>
<dl compact>
<dt>{ARG_MAX}</dt>
<dd><br>
This is defined by the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001. Unfortunately, it is very difficult for a
conforming application to deal with this value, as it does not know how much of its argument space is being consumed by the
environment variables of the user.<br>
</dd>
<dt>{BC_BASE_MAX}</dt>
<dt>{BC_DIM_MAX}</dt>
<dt>{BC_SCALE_MAX}</dt>
<dd><br>
These were originally one value, {BC_SCALE_MAX}, but it was unreasonable to link all three concepts into one limit.</dd>
<dt>{CHILD_MAX}</dt>
<dd><br>
This is defined by the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</dd>
<dt>{COLL_WEIGHTS_MAX}</dt>
<dd><br>
The weights assigned to <b>order</b> can be considered as &quot;passes&quot; through the collation algorithm.</dd>
<dt>{EXPR_NEST_MAX}</dt>
<dd><br>
The value for expression nesting was borrowed from the ISO&nbsp;C standard.</dd>
<dt>{LINE_MAX}</dt>
<dd><br>
This is a global limit that affects all utilities, unless otherwise noted. The {MAX_CANON} value from the System Interfaces volume
of IEEE&nbsp;Std&nbsp;1003.1-2001 may further limit input lines from terminals. The {LINE_MAX} value was the subject of much debate
and is a compromise between those who wished to have unlimited lines and those who understood that many historical utilities were
written with fixed buffers. Frequently, utility writers selected the UNIX system constant BUFSIZ to allocate these buffers;
therefore, some utilities were limited to 512 bytes for I/O lines, while others achieved 4096 bytes or greater.
<p>It should be noted that {LINE_MAX} applies only to input line length; there is no requirement in IEEE&nbsp;Std&nbsp;1003.1-2001
that limits the length of output lines. Utilities such as <a href="../utilities/awk.html"><i>awk</i></a>, <a href=
"../utilities/sed.html"><i>sed</i></a>, and <a href="../utilities/paste.html"><i>paste</i></a> could theoretically construct lines
longer than any of the input lines they received, depending on the options used or the instructions from the application. They are
not required to truncate their output to {LINE_MAX}. It is the responsibility of the application to deal with this. If the output
of one of those utilities is to be piped into another of the standard utilities, line length restrictions will have to be
considered; the <a href="../utilities/fold.html"><i>fold</i></a> utility, among others, could be used to ensure that only
reasonable line lengths reach utilities or applications.</p>
</dd>
<dt>{LINK_MAX}</dt>
<dd><br>
This is defined by the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</dd>
<dt>{MAX_CANON}</dt>
<dt>{MAX_INPUT}</dt>
<dt>{NAME_MAX}</dt>
<dt>{NGROUPS_MAX}</dt>
<dt>{OPEN_MAX}</dt>
<dt>{PATH_MAX}</dt>
<dt>{PIPE_BUF}</dt>
<dd><br>
These limits are defined by the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001. Note that the byte lengths described by
some of these values continue to represent bytes, even if the applicable character set uses a multi-byte encoding.</dd>
<dt>{RE_DUP_MAX}</dt>
<dd><br>
The value selected is consistent with historical practice. Although the name implies that it applies to all REs, only BREs use the
interval notation <b>\{</b><i>m,n</i><b>\}</b> addressed by this limit.</dd>
<dt>{POSIX2_SYMLINKS}</dt>
<dd><br>
The {POSIX2_SYMLINKS} variable indicates that the underlying operating system supports the creation of symbolic links in specific
directories. Many of the utilities defined in IEEE&nbsp;Std&nbsp;1003.1-2001 that deal with symbolic links do not depend on this
value. For example, a utility that follows symbolic links (or does not, as the case may be) will only be affected by a symbolic
link if it encounters one. Presumably, a file system that does not support symbolic links will not contain any. This variable does
affect such utilities as <a href="../utilities/ln.html"><i>ln</i></a> <b>-s</b> and <a href="../utilities/pax.html"><i>pax</i></a>
that attempt to create symbolic links.
<p>{POSIX2_SYMLINKS} was developed even though there is no comparable configuration value for the system interfaces.</p>
</dd>
</dl>
<p>There are different limits associated with command lines and input to utilities, depending on the method of invocation. In the
case of a C program <i>exec</i>-ing a utility, {ARG_MAX} is the underlying limit. In the case of the shell reading a script and
<i>exec</i>-ing a utility, {LINE_MAX} limits the length of lines the shell is required to process, and {ARG_MAX} will still be a
limit. If a user is entering a command on a terminal to the shell, requesting that it invoke the utility, {MAX_INPUT} may restrict
the length of the line that can be given to the shell to a value below {LINE_MAX}.</p>
<p>When an option is supported, <a href="../utilities/getconf.html"><i>getconf</i></a> returns a value of 1. For example, when C
development is supported:</p>
<blockquote>
<pre>
<tt>if [ "$(getconf POSIX2_C_DEV)" -eq 1 ]; then
echo C supported
fi
</tt>
</pre>
</blockquote>
<p>The <a href="../functions/sysconf.html"><i>sysconf</i>()</a> function in the C-Language Binding option would return 1.</p>
<p>The following comments describe selection criteria for the symbols and their values:</p>
<dl compact>
<dt>POSIX2_C_BIND</dt>
<dt>POSIX2_C_DEV</dt>
<dt>POSIX2_FORT_DEV</dt>
<dt>POSIX2_FORT_RUN</dt>
<dt>POSIX2_SW_DEV</dt>
<dt>POSIX2_UPE</dt>
<dd><br>
It is possible for some (usually privileged) operations to remove utilities that support these options or otherwise to render these
options unsupported. The header files, the <a href="../functions/sysconf.html"><i>sysconf</i>()</a> function, or the <a href=
"../utilities/getconf.html"><i>getconf</i></a> utility will not necessarily detect such actions, in which case they should not be
considered as rendering the implementation non-conforming. A test suite should not attempt tests such as:
<pre>
<tt>rm /usr/bin/c99
getconf POSIX2_C_DEV
</tt>
</pre>
</dd>
<dt>POSIX2_LOCALEDEF</dt>
<dd><br>
This symbol was introduced to allow implementations to restrict supported locales to only those supplied by the
implementation.</dd>
</dl>
<h4><a name="tag_02_01_10"></a>Grammar Conventions</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_02_01_11"></a>Utility Description Defaults</h4>
<p>This section is arranged with headings in the same order as all the utility descriptions. It is a collection of related and
unrelated information concerning:</p>
<ol>
<li>
<p>The default actions of utilities</p>
</li>
<li>
<p>The meanings of notations used in IEEE&nbsp;Std&nbsp;1003.1-2001 that are specific to individual utility sections</p>
</li>
</ol>
<p>Although this material may seem out of place here, it is important that this information appear before any of the utilities to
be described later.</p>
<h5><a name="tag_02_01_11_01"></a>NAME</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_02"></a>SYNOPSIS</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_03"></a>DESCRIPTION</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_04"></a>OPTIONS</h5>
<p>Although it has not always been possible, the standard developers tried to avoid repeating information to reduce the risk that
duplicate explanations could each be modified differently.</p>
<p>The need to recognize <b>--</b> is required because conforming applications need to shield their operands from any arbitrary
options that the implementation may provide as an extension. For example, if the standard utility <i>foo</i> is listed as taking no
options, and the application needed to give it a pathname with a leading hyphen, it could safely do it as:</p>
<pre>
<tt>foo -- -myfile
</tt>
</pre>
<p>and avoid any problems with <b>-m</b> used as an extension.</p>
<h5><a name="tag_02_01_11_05"></a>OPERANDS</h5>
<p>The usage of <b>-</b> is never shown in the SYNOPSIS. Similarly, the usage of <b>--</b> is never shown.</p>
<p>The requirement for processing operands in command-line order is to avoid a &quot;WeirdNIX&quot; utility that might choose to sort the
input files alphabetically, by size, or by directory order. Although this might be acceptable for some utilities, in general the
programmer has a right to know exactly what order will be chosen.</p>
<p>Some of the standard utilities take multiple <i>file</i> operands and act as if they were processing the concatenation of those
files. For example:</p>
<blockquote>
<pre>
<tt>asa file1 file2
</tt>
</pre>
</blockquote>
<p>and:</p>
<blockquote>
<pre>
<tt>cat file1 file2 | asa
</tt>
</pre>
</blockquote>
<p>have similar results when questions of file access, errors, and performance are ignored. Other utilities such as <a href=
"../utilities/grep.html"><i>grep</i></a> or <a href="../utilities/wc.html"><i>wc</i></a> have completely different results in these
two cases. This latter type of utility is always identified in its DESCRIPTION or OPERANDS sections, whereas the former is not.
Although it might be possible to create a general assertion about the former case, the following points must be addressed:</p>
<ul>
<li>
<p>Access times for the files might be different in the operand case <i>versus</i> the <a href=
"../utilities/cat.html"><i>cat</i></a> case.</p>
</li>
<li>
<p>The utility may have error messages that are cognizant of the input filename, and this added value should not be suppressed. (As
an example, <a href="../utilities/awk.html"><i>awk</i></a> sets a variable with the filename at each file boundary.)</p>
</li>
</ul>
<h5><a name="tag_02_01_11_06"></a>STDIN</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_07"></a>INPUT FILES</h5>
<p>A conforming application cannot assume the following three commands are equivalent:</p>
<pre>
<tt>tail -n +2 file
(sed -n 1q; cat) &lt; file
cat file | (sed -n 1q; cat)
</tt>
</pre>
<p>The second command is equivalent to the first only when the file is seekable. In the third command, if the file offset in the
open file description were not unspecified, <a href="../utilities/sed.html"><i>sed</i></a> would have to be implemented so that it
read from the pipe 1 byte at a time or it would have to employ some method to seek backwards on the pipe. Such functionality is not
defined currently in POSIX.1 and does not exist on all historical systems. Other utilities, such as <a href=
"../utilities/head.html"><i>head</i></a>, <a href="../utilities/read.html"><i>read</i></a>, and <a href=
"../utilities/sh.html"><i>sh</i></a>, have similar properties, so the restriction is described globally in this section.</p>
<p>The definition of &quot;text file&quot; is strictly enforced for input to the standard utilities; very few of them list exceptions to
the undefined results called for here. (Of course, &quot;undefined&quot; here does not mean that historical implementations necessarily
have to change to start indicating error conditions. Conforming applications cannot rely on implementations succeeding or failing
when non-text files are used.)</p>
<p>The utilities that allow line continuation are generally those that accept input languages, rather than pure data. It would be
unusual for an input line of this type to exceed {LINE_MAX} bytes and unreasonable to require that the implementation allow
unlimited accumulation of multiple lines, each of which could reach {LINE_MAX}. Thus, for a conforming application the total of all
the continued lines in a set cannot exceed {LINE_MAX}.</p>
<p>The format description is intended to be sufficiently rigorous to allow other applications to generate these input files.
However, since &lt;blank&gt;s can legitimately be included in some of the fields described by the standard utilities, particularly
in locales other than the POSIX locale, this intent is not always realized.</p>
<h5><a name="tag_02_01_11_08"></a>ENVIRONMENT VARIABLES</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_09"></a>ASYNCHRONOUS EVENTS</h5>
<p>Because there is no language prohibiting it, a utility is permitted to catch a signal, perform some additional processing (such
as deleting temporary files), restore the default signal action (or action inherited from the parent process), and resignal
itself.</p>
<h5><a name="tag_02_01_11_10"></a>STDOUT</h5>
<p>The format description is intended to be sufficiently rigorous to allow post-processing of output by other programs,
particularly by an <a href="../utilities/awk.html"><i>awk</i></a> or <a href="../utilities/lex.html"><i>lex</i></a> parser.</p>
<h5><a name="tag_02_01_11_11"></a>STDERR</h5>
<p>This section does not describe error messages that refer to incorrect operation of the utility. Consider a utility that
processes program source code as its input. This section is used to describe messages produced by a correctly operating utility
that encounters an error in the program source code on which it is processing. However, a message indicating that the utility had
insufficient memory in which to operate would not be described.</p>
<p>Some utilities have traditionally produced warning messages without returning a non-zero exit status; these are specifically
noted in their sections. Other utilities shall not write to standard error if they complete successfully, unless the implementation
provides some sort of extension to increase the verbosity or debugging level.</p>
<p>The format descriptions are intended to be sufficiently rigorous to allow post-processing of output by other programs.</p>
<h5><a name="tag_02_01_11_12"></a>OUTPUT FILES</h5>
<p>The format description is intended to be sufficiently rigorous to allow post-processing of output by other programs,
particularly by an <a href="../utilities/awk.html"><i>awk</i></a> or <a href="../utilities/lex.html"><i>lex</i></a> parser.</p>
<p>Receipt of the SIGQUIT signal should generally cause termination (unless in some debugging mode) that would bypass any attempted
recovery actions.</p>
<h5><a name="tag_02_01_11_13"></a>EXTENDED DESCRIPTION</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_14"></a>EXIT STATUS</h5>
<p>Note the additional discussion of exit values in <i>Exit Status for Commands</i> in the <a href=
"../utilities/sh.html"><i>sh</i></a> utility. It describes requirements for returning exit values greater than 125.</p>
<p>A utility may list zero as a successful return, 1 as a failure for a specific reason, and greater than 1 as &quot;an error
occurred&quot;. In this case, unspecified conditions may cause a 2 or 3, or other value, to be returned. A strictly conforming
application should be written so that it tests for successful exit status values (zero in this case), rather than relying upon the
single specific error value listed in IEEE&nbsp;Std&nbsp;1003.1-2001. In that way, it will have maximum portability, even on
implementations with extensions.</p>
<p>The standard developers are aware that the general non-enumeration of errors makes it difficult to write test suites that test
the <i>incorrect</i> operation of utilities. There are some historical implementations that have expended effort to provide
detailed status messages and a helpful environment to bypass or explain errors, such as prompting, retrying, or ignoring
unimportant syntax errors; other implementations have not. Since there is no realistic way to mandate system behavior in cases of
undefined application actions or system problems-in a manner acceptable to all cultures and environments-attention has been limited
to the correct operation of utilities by the conforming application. Furthermore, the conforming application does not need detailed
information concerning errors that it caused through incorrect usage or that it cannot correct.</p>
<p>There is no description of defaults for this section because all of the standard utilities specify something (or explicitly
state &quot;Unspecified&quot;) for exit status.</p>
<h5><a name="tag_02_01_11_15"></a>CONSEQUENCES OF ERRORS</h5>
<p>Several actions are possible when a utility encounters an error condition, depending on the severity of the error and the state
of the utility. Included in the possible actions of various utilities are: deletion of temporary or intermediate work files;
deletion of incomplete files; and validity checking of the file system or directory.</p>
<p>The text about recursive traversing is meant to ensure that utilities such as <a href="../utilities/find.html"><i>find</i></a>
process as many files in the hierarchy as they can. They should not abandon all of the hierarchy at the first error and resume with
the next command-line operand, but should attempt to keep going.</p>
<h5><a name="tag_02_01_11_16"></a>APPLICATION USAGE</h5>
<p>This section provides additional caveats, issues, and recommendations to the developer.</p>
<h5><a name="tag_02_01_11_17"></a>EXAMPLES</h5>
<p>This section provides sample usage.</p>
<h5><a name="tag_02_01_11_18"></a>RATIONALE</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_19"></a>FUTURE DIRECTIONS</h5>
<p>FUTURE DIRECTIONS sections act as pointers to related work that may impact the interface in the future, and often cautions the
developer to architect the code to account for a change in this area. Note that a future directions statement should not be taken
as a commitment to adopt a feature or interface in the future.</p>
<h5><a name="tag_02_01_11_20"></a>SEE ALSO</h5>
<p>There is no additional rationale provided for this section.</p>
<h5><a name="tag_02_01_11_21"></a>CHANGE HISTORY</h5>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_02_01_12"></a>Considerations for Utilities in Support of Files of Arbitrary Size</h4>
<p>This section is intended to clarify the requirements for utilities in support of large files.</p>
<p>The utilities listed in this section are utilities which are used to perform administrative tasks such as to create, move, copy,
remove, change the permissions, or measure the resources of a file. They are useful both as end-user tools and as utilities invoked
by applications during software installation and operation.</p>
<p>The <a href="../utilities/chgrp.html"><i>chgrp</i></a>, <a href="../utilities/chmod.html"><i>chmod</i></a>, <a href=
"../utilities/chown.html"><i>chown</i></a>, <a href="../utilities/ln.html"><i>ln</i></a>, and <a href=
"../utilities/rm.html"><i>rm</i></a> utilities probably require use of large file-capable versions of <a href=
"../functions/stat.html"><i>stat</i>()</a>, <a href="../functions/lstat.html"><i>lstat</i>()</a>, <a href=
"../functions/ftw.html"><i>ftw</i>()</a>, and the <b>stat</b> structure.</p>
<p>The <a href="../utilities/cat.html"><i>cat</i></a>, <a href="../utilities/cksum.html"><i>cksum</i></a>, <a href=
"../utilities/cmp.html"><i>cmp</i></a>, <a href="../utilities/cp.html"><i>cp</i></a>, <a href="../utilities/dd.html"><i>dd</i></a>,
<a href="../utilities/mv.html"><i>mv</i></a>, <i>sum</i>, and <a href="../utilities/touch.html"><i>touch</i></a> utilities probably
require use of large file-capable versions of <a href="../functions/creat.html"><i>creat</i>()</a>, <a href=
"../functions/open.html"><i>open</i>()</a>, and <a href="../functions/fopen.html"><i>fopen</i>()</a>.</p>
<p>The <a href="../utilities/cat.html"><i>cat</i></a>, <a href="../utilities/cksum.html"><i>cksum</i></a>, <a href=
"../utilities/cmp.html"><i>cmp</i></a>, <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/df.html"><i>df</i></a>,
<a href="../utilities/du.html"><i>du</i></a>, <a href="../utilities/ls.html"><i>ls</i></a>, and <i>sum</i> utilities may require
writing large integer values. For example:</p>
<ul>
<li>
<p>The <a href="../utilities/cat.html"><i>cat</i></a> utility might have a <b>-n</b> option which counts &lt;newline&gt;s.</p>
</li>
<li>
<p>The <a href="../utilities/cksum.html"><i>cksum</i></a> and <a href="../utilities/ls.html"><i>ls</i></a> utilities report file
sizes.</p>
</li>
<li>
<p>The <a href="../utilities/cmp.html"><i>cmp</i></a> utility reports the line number at which the first difference occurs, and
also has a <b>-l</b> option which reports file offsets.</p>
</li>
<li>
<p>The <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/df.html"><i>df</i></a>, <a href=
"../utilities/du.html"><i>du</i></a>, <a href="../utilities/ls.html"><i>ls</i></a>, and <i>sum</i> utilities report block
counts.</p>
</li>
</ul>
<p>The <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/find.html"><i>find</i></a>, and <a href=
"../utilities/test.html"><i>test</i></a> utilities may need to interpret command arguments that contain 64-bit values. For <a href=
"../utilities/dd.html"><i>dd</i></a>, the arguments include <i>skip</i>= <i>n</i>, <i>seek</i>= <i>n</i>, and <i>count</i>=
<i>n</i>. For <a href="../utilities/find.html"><i>find</i></a>, the arguments include <b>-size</b> <i>n</i>. For <a href=
"../utilities/test.html"><i>test</i></a>, the arguments are those associated with algebraic comparisons.</p>
<p>The <a href="../utilities/df.html"><i>df</i></a> utility might need to access large file systems with <a href=
"../functions/statvfs.html"><i>statvfs</i>()</a>.</p>
<p>The <a href="../utilities/ulimit.html"><i>ulimit</i></a> utility will need to use large file-capable versions of <a href=
"../functions/getrlimit.html"><i>getrlimit</i>()</a> and <a href="../functions/setrlimit.html"><i>setrlimit</i>()</a> and be able
to read and write large integer values.</p>
<h4><a name="tag_02_01_13"></a>Built-In Utilities</h4>
<p>All of these utilities can be <i>exec</i>-ed. There is no requirement that these utilities are actually built into the shell
itself, but many shells need the capability to do so because the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap02.html#tag_02_09_01_01">Section 2.9.1.1, Command Search and Execution</a> requires that they be found
prior to the <i>PATH</i> search. The shell could satisfy its requirements by keeping a list of the names and directly accessing the
file-system versions regardless of <i>PATH .</i> Providing all of the required functionality for those such as <a href=
"../utilities/cd.html"><i>cd</i></a> or <a href="../utilities/read.html"><i>read</i></a> would be more difficult.</p>
<p>There were originally three justifications for allowing the omission of <i>exec</i>-able versions:</p>
<ol>
<li>
<p>It would require wasting space in the file system, at the expense of very small systems. However, it has been pointed out that
all 16 utilities in the table can be provided with 16 links to a single-line shell script:</p>
<pre>
<tt>$0 "$@"
</tt>
</pre>
</li>
<li>
<p>It is not logical to require invocation of utilities such as <a href="../utilities/cd.html"><i>cd</i></a> because they have no
value outside the shell environment or cannot be useful in a child process. However, counter-examples always seemed to be available
for even the most unusual cases:</p>
<pre>
<tt>find . -type d -exec cd {} \; -exec foo {} \;
</tt> (which invokes &quot;foo&quot; on accessible directories)<tt><br>
ps ... | sed ... | xargs kill
<br>
find . -exec true \; -a ...
</tt> (where &quot;true&quot; is used for temporary debugging)
</pre>
</li>
<li>
<p>It is confusing to have a utility such as <a href="../utilities/kill.html"><i>kill</i></a> that can easily be in the file system
in the base standard, but that requires built-in status for the User Portability Utilities option (for the <tt>%</tt> job control
job ID notation). It was decided that it was more appropriate to describe the required functionality (rather than the
implementation) to the system implementors and let them decide how to satisfy it.</p>
</li>
</ol>
<p>On the other hand, it was realized that any distinction like this between utilities was not useful to applications, and that the
cost to correct it was small. These arguments were ultimately the most effective.</p>
<p>There were varying reasons for including utilities in the table of built-ins:</p>
<dl compact>
<dt><i>alias</i>, <i>fc</i>, <i>unalias</i></dt>
<dd><br>
The functionality of these utilities is performed more simply within the shell itself and that is the model most historical
implementations have used.</dd>
<dt><i>bg</i>, <i>fg</i>, <i>jobs</i></dt>
<dd><br>
All of the job control-related utilities are eligible for built-in status because that is the model most historical implementations
have used.</dd>
<dt><i>cd</i>, <i>getopts</i>, <i>newgrp</i>, <i>read</i>, <i>umask</i>, <i>wait</i></dt>
<dd><br>
The functionality of these utilities is performed more simply within the context of the current process. An example can be taken
from the usage of the <a href="../utilities/cd.html"><i>cd</i></a> utility. The purpose of the <a href=
"../utilities/cd.html"><i>cd</i></a> utility is to change the working directory for subsequent operations. The actions of <a href=
"../utilities/cd.html"><i>cd</i></a> affect the process in which <a href="../utilities/cd.html"><i>cd</i></a> is executed and all
subsequent child processes of that process. Based on the POSIX standard process model, changes in the process environment of a
child process have no effect on the parent process. If the <a href="../utilities/cd.html"><i>cd</i></a> utility were executed from
a child process, the working directory change would be effective only in the child process. Child processes initiated subsequent to
the child process that executed the <a href="../utilities/cd.html"><i>cd</i></a> utility would not have a changed working directory
relative to the parent process.</dd>
<dt><i>command</i></dt>
<dd><br>
This utility was placed in the table primarily to protect scripts that are concerned about their <i>PATH</i> being manipulated. The
&quot;secure&quot; shell script example in the <a href="../utilities/command.html"><i>command</i></a> utility in the Shell and Utilities
volume of IEEE&nbsp;Std&nbsp;1003.1-2001 would not be possible if a <i>PATH</i> change retrieved an alien version of <a href=
"../utilities/command.html"><i>command</i></a>. (An alternative would have been to implement <a href=
"../utilities/getconf.html"><i>getconf</i></a> as a built-in, but the standard developers considered that it carried too many
changing configuration strings to require in the shell.)</dd>
<dt><i>kill</i></dt>
<dd>Since <a href="../utilities/kill.html"><i>kill</i></a> provides optional job control functionality using shell notation (
<tt>%1</tt> , <tt>%2</tt> , and so on), some implementations would find it extremely difficult to provide this outside the
shell.</dd>
<dt><i>true</i>, <i>false</i></dt>
<dd><br>
These are in the table as a courtesy to programmers who wish to use the <tt>"while&nbsp;true"</tt> shell construct without
protecting <a href="../utilities/true.html"><i>true</i></a> from <i>PATH</i> searches. (It is acknowledged that
<tt>"while&nbsp;:"</tt> also works, but the idiom with <a href="../utilities/true.html"><i>true</i></a> is historically
pervasive.)</dd>
</dl>
<p>All utilities, including those in the table, are accessible via the <a href="../functions/system.html"><i>system</i>()</a> and
<a href="../functions/popen.html"><i>popen</i>()</a> functions in the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001.
There are situations where the return functionality of <a href="../functions/system.html"><i>system</i>()</a> and <a href=
"../functions/popen.html"><i>popen</i>()</a> is not desirable. Applications that require the exit status of the invoked utility
will not be able to use <a href="../functions/system.html"><i>system</i>()</a> or <a href=
"../functions/popen.html"><i>popen</i>()</a>, since the exit status returned is that of the command language interpreter rather
than that of the invoked utility. The alternative for such applications is the use of the <i>exec</i> family.</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>

1839
Ref-docs/POSIX/susv3/xrat/xcu_chap02.html Normal file
View File

File diff suppressed because it is too large Load Diff

421
Ref-docs/POSIX/susv3/xrat/xcu_chap03.html Normal file
View File

@@ -0,0 +1,421 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_02_03"></a>Batch Environment Services and Utilities</h3>
<h5><a name="tag_02_03_00_01"></a>Scope of the Batch Environment Option</h5>
<p>This section summarizes the deliberations of the IEEE P1003.15 (Batch Environment) working group in the development of the Batch
Environment option, which covers a set of services and utilities defining a batch processing system.</p>
<p>This informative section contains historical information concerning the contents of the amendment and describes why features
were included or discarded by the working group.</p>
<h5><a name="tag_02_03_00_02"></a>History of Batch Systems</h5>
<p>The supercomputing technical committee began as a &quot;Birds Of a Feather&quot; (BOF) at the January 1987 Usenix meeting. There was
enough general interest to form a supercomputing attachment to the /usr/group working groups. Several subgroups rapidly formed. Of
those subgroups, the batch group was the most ambitious. The first early meetings were spent evaluating user needs and existing
batch implementations.</p>
<p>To evaluate user needs, individuals from the supercomputing community came and presented their needs. Common requests were
flexibility, interoperability, control of resources, and ease-of-use. Backward-compatibility was not an issue. The working group
then evaluated some existing systems. The following different systems were evaluated:</p>
<ul>
<li>
<p>PROD</p>
</li>
<li>
<p>Convex Distributed Batch</p>
</li>
<li>
<p>NQS</p>
</li>
<li>
<p>CTSS</p>
</li>
<li>
<p>MDQS from Ballistics Research Laboratory (BRL)</p>
</li>
</ul>
<p>Finally, NQS was chosen as a model because it satisfied not only the most user requirements, but because it was public domain,
already implemented on a variety of hardware platforms, and network-based.</p>
<h5><a name="tag_02_03_00_03"></a>Historical Implementations of Batch Systems</h5>
<p>Deferred processing of work under the control of a scheduler has been a feature of most proprietary operating systems from the
earliest days of multi-user systems in order to maximize utilization of the computer.</p>
<p>The arrival of UNIX systems proved to be a dilemma to many hardware providers and users because it did not include the
sophisticated batch facilities offered by the proprietary systems. This omission was rectified in 1986 by NASA Ames Research Center
who developed the Network Queuing System (NQS) as a portable UNIX application that allowed the routing and processing of batch
&quot;jobs&quot; in a network. To encourage its usage, the product was later put into the public domain. It was promptly picked up by UNIX
hardware providers, and ported and developed for their respective hardware and UNIX implementations.</p>
<p>Many major vendors, who traditionally offer a batch-dominated environment, ported the public-domain product to their systems,
customized it to support the capabilities of their systems, and added many customer-requested features.</p>
<p>Due to the strong hardware provider and customer acceptance of NQS, it was decided to use NQS as the basis for the POSIX Batch
Environment amendment in 1987. Other batch systems considered at the time included CTSS, MDQS (a forerunner of NQS from the
Ballistics Research Laboratory), and PROD (a Los Alamos Labs development). None were thought to have both the functionality and
acceptability of NQS.</p>
<h5><a name="tag_02_03_00_04"></a>NQS Differences from the at utility</h5>
<p>The base standard <a href="../utilities/at.html"><i>at</i></a> and <a href="../utilities/batch.html"><i>batch</i></a> utilities
are not sufficient to meet the batch processing needs in a supercomputing environment and additional functionality in the areas of
resource management, job scheduling, system management, and control of output is required.</p>
<h5><a name="tag_02_03_00_05"></a>Batch Environment Option Definitions</h5>
<p>The concept of a batch job is closely related to a session with a session leader. The main difference is that a batch job does
not have a controlling terminal. There has been much debate over whether to use the term &quot;request&quot; or &quot;job&quot;. Job was the final
choice because of the historical use of this term in the batch environment.</p>
<p>The current definition for job identifiers is not sufficient with the model of destinations. The current definition is:</p>
<blockquote>
<pre>
<tt>sequence_number.originating_host
</tt>
</pre>
</blockquote>
<p>Using the model of destination, a host may include multiple batch nodes, the location of which is identified uniquely by a name
or directory service. If the current definition is used, batch nodes running on the same host would have to coordinate their use of
sequence numbers, as sequence numbers are assigned by the originating host. The alternative is to use the originating batch node
name instead of the originating host name.</p>
<p>The reasons for wishing to run more than one batch system per host could be the following.</p>
<p>A test and production batch system are maintained on a single host. This is most likely in a development facility, but could
also arise when a site is moving from one version to another. The new batch system could be installed as a test version that is
completely separate from the production batch system, so that problems can be isolated to the test system. Requiring the batch
nodes to coordinate their use of sequence numbers creates a dependency between the two nodes, and that defeats the purpose of
running two nodes.</p>
<p>A site has multiple departments using a single host, with different management policies. An example of contention might be in
job selection algorithms. One group might want a FIFO type of selection, while another group wishes to use a more complex algorithm
based on resource availability. Again, requiring the batch nodes to coordinate is an unnecessary binding.</p>
<p>The proposal eventually accepted was to replace originating host with originating batch node. This supplies sufficient
granularity to ensure unique job identifiers. If more than one batch node is on a particular host, they each have their own unique
name.</p>
<p>The queue portion of a destination is not part of the job identifier as these are not required to be unique between batch nodes.
For instance, two batch nodes may both have queues called small, medium, and large. It is only the batch node name that is uniquely
identifiable throughout the batch system. The queue name has no additional function in this context.</p>
<p>Assume there are three batch nodes, each of which has its own name server. On batch node one, there are no queues. On batch node
two, there are fifty queues. On batch node three, there are forty queues. The system administrator for batch node one does not have
to configure queues, because there are none implemented. However, if a user wishes to send a job to either batch node two or three,
the system administrator for batch node one must configure a destination that maps to the appropriate batch node and queue. If
every queue is to be made accessible from batch node one, the system administrator has to configure ninety destinations.</p>
<p>To avoid requiring this, there should be a mechanism to allow a user to separate the destination into a batch node name and a
queue name. Then, an implementation that is configured to get to all the batch nodes does not need any more configuration to allow
a user to get to all of the queues on all of the batch nodes. The node name is used to locate the batch node, while the queue name
is sent unchanged to that batch node.</p>
<p>The following are requirements that a destination identifier must be capable of providing:</p>
<ul>
<li>
<p>The ability to direct a job to a queue in a particular batch node.</p>
</li>
<li>
<p>The ability to direct a job to a particular batch node.</p>
</li>
<li>
<p>The ability to group at a higher level than just one queue. This includes grouping similar queues across multiple batch nodes
(this is a pipe queue).</p>
</li>
<li>
<p>The ability to group batch nodes. This allows a user to submit a job to a group name with no knowledge of the batch node
configuration. This also provides aliasing as a special case. Aliasing is a group containing only one batch node name. The group
name is the alias.</p>
</li>
</ul>
<p>In addition, the administrator has the following requirements:</p>
<ul>
<li>
<p>The ability to control access to the queues.</p>
</li>
<li>
<p>The ability to control access to the batch nodes.</p>
</li>
<li>
<p>The ability to control access to groups of queues (pipe queues).</p>
</li>
<li>
<p>The ability to configure retry time intervals and durations.</p>
</li>
</ul>
<p>The requirements of the user are met by destination as explained in the following.</p>
<p>The user has the ability to specify a queue name, which is known only to the batch node specified. There is no configuration of
these queues required on the submitting node.</p>
<p>The user has the ability to specify a batch node whose name is network-unique. The configuration required is that the batch node
be defined as an application, just as other applications such as FTP are configured.</p>
<p>Once a job reaches a queue, it can again become a user of the batch system. The batch node can choose to send the job to another
batch node or queue or both. In other words, the routing is at an application level, and it is up to the batch system to choose
where the job will be sent. Configuration is up to the batch node where the queue resides. This provides grouping of queues across
batch nodes or within a batch node. The user submits the job to a queue, which by definition routes the job to other queues or
nodes or both.</p>
<p>A node name may be given to a naming service, which returns multiple addresses as opposed to just one. This provides grouping at
a batch node level. This is a local issue, meaning that the batch node must choose only one of these addresses. The list of
addresses is not sent with the job, and once the job is accepted on another node, there is no connection between the list and the
job. The requirements of the administrator are met by destination as explained in the following.</p>
<p>The control of queues is a batch system issue, and will be done using the batch administrative utilities.</p>
<p>The control of nodes is a network issue, and will be done through whatever network facilities are available.</p>
<p>The control of access to groups of queues (pipe queues) is covered by the control of any other queue. The fact that the job may
then be sent to another destination is not relevant.</p>
<p>The propagation of a job across more than one point-to-point connection was dropped because of its complexity and because all of
the issues arising from this capability could not be resolved. It could be provided as additional functionality at some time in the
future.</p>
<p>The addition of <i>network</i> as a defined term was done to clarify the difference between a network of batch nodes as opposed
to a network of hosts. A network of batch nodes is referred to as a batch system. The network refers to the actual host
configuration. A single host may have multiple batch nodes.</p>
<p>In the absence of a standard network naming convention, this option establishes its own convention for the sake of consistency
and expediency. This is subject to change, should a future working group develop a standard naming convention for network
pathnames.</p>
<h4><a name="tag_02_03_01"></a>Batch General Concepts</h4>
<p>During the development of the Batch Environment option, a number of topics were discussed at length which influenced the wording
of the normative text but could not be included in the final text. The following items are some of the most significant terms and
concepts of those discussed:</p>
<ul>
<li>
<p>Small and Consistent Command Set</p>
<p>Often, conventional utilities from UNIX systems have a very complicated utility syntax and usage. This can often result in
confusion and errors when trying to use them. The Batch Environment option utility set, on the other hand, has been paired to a
small set of robust utilities with an orthogonal calling sequence.</p>
</li>
<li>
<p>Checkpoint/Restart</p>
<p>This feature permits an already executing process to checkpoint or save its contents. Some implementations permit this at both
the batch utility level (for example, checkpointing this job upon its abnormal termination) or from within the job itself via a
system call. Support of checkpoint/restart is optional. A conscious, careful effort was made to make the <a href=
"../utilities/qsub.html"><i>qsub</i></a> utility consistently refer to checkpoint/restart as optional functionality.</p>
</li>
<li>
<p>Rerunability</p>
<p>When a user submits a job for batch processing, they can designate it &quot;rerunnable&quot; in that it will automatically resume
execution from the start of the job if the machine on which it was executing crashes for some reason. The decision on whether the
job will be rerun or not is entirely up to the submitter of the job and no decisions will be made within the batch system. A job
that is rerunnable and has been submitted with the proper checkpoint/restart switch will first be checkpointed and execution begun
from that point. Furthermore, use of the implementation-defined checkpoint/restart feature will not be defined in this context.</p>
</li>
<li>
<p>Error Codes</p>
<p>All utilities exit with error status zero (0) if successful, one (1) if a user error occurred, and two (2) for an internal Batch
Environment option error.</p>
</li>
<li>
<p>Level of Portability</p>
<p>Portability is specified at both the user, operator, and administrator levels. A conforming batch implementation prevents
identical functionality and behavior at all these levels. Additionally, portable batch shell scripts with embedded Batch
Environment option utilities add an additional level of portability.</p>
</li>
<li>
<p>Resource Specification</p>
<p>A small set of globally understood resources, such as memory and CPU time, is specified. All conforming batch implementations
are able to process them in a manner consistent with the yet-to-be-developed resource management model. Resources not in this
amendment set are ignored and passed along as part of the argument stream of the utility.</p>
</li>
<li>
<p>Queue Position</p>
<p>Queue position is the place a job occupies in a queue. It is dependent on a variety of factors such as submission time and
priority. Since priority may be affected by the implementation of fair share scheduling, the definition of queue position is
implementation-defined.</p>
</li>
<li>
<p>Queue ID</p>
<p>A numerical queue ID is an external requirement for purposes of accounting. The identification number was chosen over queue name
for processing convenience.</p>
</li>
<li>
<p>Job ID</p>
<p>A common notion of &quot;jobs&quot; is a collection of processes whose process group cannot be altered and is used for resource
management and accounting. This concept is implementation-defined and, as such, has been omitted from the batch amendment.</p>
</li>
<li>
<p>Bytes <i>versus</i> Words</p>
<p>Except for one case, bytes are used as the standard unit for memory size. Furthermore, the definition of a word varies from
machine to machine. Therefore, bytes will be the default unit of memory size.</p>
</li>
<li>
<p>Regular Expressions</p>
<p>The standard definition of regular expressions is much too broad to be used in the batch utility syntax. All that is needed is a
simple concept of &quot;all''; for example, delete all my jobs from the named queue. For this reason, regular expressions have been
eliminated from the batch amendment.</p>
</li>
<li>
<p>Display Privacy</p>
<p>How much data should be displayed locally through functions? Local policy dictates the amount of privacy. Library functions must
be used to create and enforce local policy. Network and local <a href="../utilities/qstat.html"><i>qstat</i></a>s must reflect the
policy of the server machine.</p>
</li>
<li>
<p>Remote Host Naming Convention</p>
<p>It was decided that host names would be a maximum of 255 characters in length, with at most 15 characters being shown in
displays. The 255 character limit was chosen because it is consistent with BSD. The 15-character limit was an arbitrary
decision.</p>
</li>
<li>
<p>Network Administration</p>
<p>Network administration is important, but is outside the scope of the batch amendment. Network administration could be done with
<i>rsh</i>. However, authentication becomes two-sided.</p>
</li>
<li>
<p>Network Administration Philosophy</p>
<p>Keep it simple. Centralized management should be possible. For example, Los Alamos needs a dumb set of CPUs to be managed by a
central system <i>versus</i> several independently-managed systems as is the general case for the Batch Environment option.</p>
</li>
<li>
<p>Operator Utility Defaults (that is, Default Host, User, Account, and so on)</p>
<p>It was decided that usability would override orthogonality and syntactic consistency.</p>
</li>
<li>
<p>The Batch System Manager and Operator Distinction</p>
<p>The distinction between manager and operator is that operators can only control the flow of jobs. A manager can alter the batch
system configuration in addition to job flow. POSIX makes a distinction between user and system administrator but goes no further.
The concepts of manager and operator privileges fall under local policy. The distinction between manager and operator is historical
in batch environments, and the Batch Environment option has continued that distinction.</p>
</li>
<li>
<p>The Batch System Administrator</p>
<p>An administrator is equivalent to a batch system manager.</p>
</li>
</ul>
<h4><a name="tag_02_03_02"></a>Batch Services</h4>
<p>This rationale is provided as informative rather than normative text, to avoid placing requirements on implementors regarding
the use of symbolic constants, but at the same time to give implementors a preferred practice for assigning values to these
constants to promote interoperability.</p>
<p>The <i>Checkpoint</i> and <i>Minimum_Cpu_Interval</i> attributes induce a variety of behavior depending upon their values. Some
jobs cannot or should not be checkpointed. Other users will simply need to ensure job continuation across planned downtimes; for
example, scheduled preventive maintenance. For users consuming expensive resources, or for jobs that run longer than the mean time
between failures, however, periodic checkpointing may be essential. However, system administrators must be able to set minimum
checkpoint intervals on a queue-by-queue basis to guard against, for example, naive users specifying interval values too small on
memory-intensive jobs. Otherwise, system overhead would adversely affect performance.</p>
<p>The use of symbolic constants, such as NO_CHECKPOINT, was introduced to lend a degree of formalism and portability to this
option.</p>
<p>Support for checkpointing is optional for servers. However, clients must provide for the <b>-c</b> option, since in a
distributed environment the job may run on a server that does provide such support, even if the host of the client does not support
the checkpoint feature.</p>
<p>If the user does not specify the <b>-c</b> option, the default action is left unspecified by this option. Some implementations
may wish to do checkpointing by default; others may wish to checkpoint only under an explicit request from the user.</p>
<p>The <i>Priority</i> attribute has been made non-optional. All clients already had been required to support the <b>-p</b> option.
The concept of prioritization is common in historical implementations. The default priority is left to the server to establish.</p>
<p>The <i>Hold_Types</i> attribute has been modified to allow for implementation-defined hold types to be passed to a batch
server.</p>
<p>It was the intent of the IEEE P1003.15 working group to mandate the support for the <i>Resource_List</i> attribute in this
option by referring to another amendment, specifically the IEEE&nbsp;P1003.1a draft standard. However, during the development of
the IEEE&nbsp;P1003.1a draft standard this was excluded. As such this requirement has been removed from the normative text.</p>
<p>The <i>Shell_Path</i> attribute has been modified to accept a list of shell paths that are associated with a host. The name of
the attribute has been changed to <i>Shell_Path_List</i>.</p>
<h4><a name="tag_02_03_03"></a>Common Behavior for Batch Environment Utilities</h4>
<p>This section was defined to meet the goal of a &quot;Small and Consistent Command Set&quot; for this option.</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>

297
Ref-docs/POSIX/susv3/xrat/xcu_chap04.html Normal file
View File

@@ -0,0 +1,297 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_02_04"></a>Utilities</h3>
<p>For the utilities included in IEEE&nbsp;Std&nbsp;1003.1-2001, see the RATIONALE sections on the individual reference pages.</p>
<h5><a name="tag_02_04_00_01"></a>Exclusion of Utilities</h5>
<p>The set of utilities contained in IEEE&nbsp;Std&nbsp;1003.1-2001 is drawn from the base documents, with one addition: the <a
href="../utilities/c99.html"><i>c99</i></a> utility. This section contains rationale for some of the deliberations that led to this
set of utilities, and why certain utilities were excluded.</p>
<p>Many utilities were evaluated by the standard developers; more historical utilities were excluded from the base documents than
included. The following list contains many common UNIX system utilities that were not included as mandatory utilities, in the User
Portability Utilities option, in the XSI extension, or in one of the software development groups. It is logistically difficult for
this rationale to distribute correctly the reasons for not including a utility among the various utility options. Therefore, this
section covers the reasons for all utilities not included in IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>This rationale is limited to a discussion of only those utilities actively or indirectly evaluated by the standard developers of
the base documents, rather than the list of all known UNIX utilities from all its variants.</p>
<dl compact>
<dt><i>adb</i></dt>
<dd>The intent of the various software development utilities was to assist in the installation (rather than the actual development
and debugging) of applications. This utility is primarily a debugging tool. Furthermore, many useful aspects of <i>adb</i> are very
hardware-specific.</dd>
<dt><i>as</i></dt>
<dd>Assemblers are hardware-specific and are included implicitly as part of the compilers in IEEE&nbsp;Std&nbsp;1003.1-2001.</dd>
<dt><i>banner</i></dt>
<dd>The only known use of this command is as part of the <a href="../utilities/lp.html"><i>lp</i></a> printer header pages. It was
decided that the format of the header is implementation-defined, so this utility is superfluous to application portability.</dd>
<dt><i>calendar</i></dt>
<dd>This reminder service program is not useful to conforming applications.</dd>
<dt><i>cancel</i></dt>
<dd>The <a href="../utilities/lp.html"><i>lp</i></a> (line printer spooling) system specified is the most basic possible and did
not need this level of application control.</dd>
<dt><i>chroot</i></dt>
<dd>This is primarily of administrative use, requiring superuser privileges.</dd>
<dt><i>col</i></dt>
<dd>No utilities defined in IEEE&nbsp;Std&nbsp;1003.1-2001 produce output requiring such a filter. The <i>nroff</i> text formatter
is present on many historical systems and will continue to remain as an extension; <i>col</i> is expected to be shipped by all the
systems that ship <i>nroff</i>.</dd>
<dt><i>cpio</i></dt>
<dd>This has been replaced by <a href="../utilities/pax.html"><i>pax</i></a>, for reasons explained in the rationale for that
utility.</dd>
<dt><i>cpp</i></dt>
<dd>This is subsumed by <a href="../utilities/c99.html"><i>c99</i></a>.</dd>
<dt><i>cu</i></dt>
<dd>This utility is terminal-oriented and is not useful from shell scripts or typical application programs.</dd>
<dt><i>dc</i></dt>
<dd>The functionality of this utility can be provided by the <a href="../utilities/bc.html"><i>bc</i></a> utility; <a href=
"../utilities/bc.html"><i>bc</i></a> was selected because it was easier to use and had superior functionality. Although the
historical versions of <a href="../utilities/bc.html"><i>bc</i></a> are implemented using <i>dc</i> as a base,
IEEE&nbsp;Std&nbsp;1003.1-2001 prescribes the interface and not the underlying mechanism used to implement it.</dd>
<dt><i>dircmp</i></dt>
<dd>Although a useful concept, the historical output of this directory comparison program is not suitable for processing in
application programs. Also, the <a href="../utilities/diff.html"><i>diff</i></a> <b>-r</b> command gives equivalent
functionality.</dd>
<dt><i>dis</i></dt>
<dd>Disassemblers are hardware-specific.</dd>
<dt><i>emacs</i></dt>
<dd>The community of <i>emacs</i> editing enthusiasts was adamant that the full <i>emacs</i> editor not be included in the base
documents because they were concerned that an attempt to standardize this very powerful environment would encourage vendors to ship
versions conforming strictly to the standard, but lacking the extensibility required by the community. The author of the original
<i>emacs</i> program also expressed his desire to omit the program. Furthermore, there were a number of historical UNIX systems
that did not include <i>emacs</i>, or included it without supporting it, but there were very few that did not include and support
<a href="../utilities/vi.html"><i>vi</i></a>.</dd>
<dt><i>ld</i></dt>
<dd>This is subsumed by <a href="../utilities/c99.html"><i>c99</i></a>.</dd>
<dt><i>line</i></dt>
<dd>The functionality of <i>line</i> can be provided with <a href="../utilities/read.html"><i>read</i></a>.</dd>
<dt><i>lint</i></dt>
<dd>This technology is partially subsumed by <a href="../utilities/c99.html"><i>c99</i></a>. It is also hard to specify the degree
of checking for possible error conditions in programs in any compiler, and specifying what <i>lint</i> would do in these cases is
equally difficult.
<p>It is fairly easy to specify what a compiler does. It requires specifying the language, what it does with that language, and
stating that the interpretation of any incorrect program is unspecified. Unfortunately, any description of <i>lint</i> is required
to specify what to do with erroneous programs. Since the number of possible errors and questionable programming practices is
infinite, one cannot require <i>lint</i> to detect all errors of any given class.</p>
<p>Additionally, some vendors complained that since many compilers are distributed in a binary form without a <i>lint</i> facility
(because the ISO&nbsp;C standard does not require one), implementing the standard as a stand-alone product will be much harder.
Rather than being able to build upon a standard compiler component (simply by providing <a href=
"../utilities/c99.html"><i>c99</i></a> as an interface), source to that compiler would most likely need to be modified to provide
the <i>lint</i> functionality. This was considered a major burden on system providers for a very small gain to developers
(users).</p>
</dd>
<dt><i>login</i></dt>
<dd>This utility is terminal-oriented and is not useful from shell scripts or typical application programs.</dd>
<dt><i>lorder</i></dt>
<dd>This utility is an aid in creating an implementation-defined detail of object libraries that the standard developers did not
feel required standardization.</dd>
<dt><i>lpstat</i></dt>
<dd>The <a href="../utilities/lp.html"><i>lp</i></a> system specified is the most basic possible and did not need this level of
application control.</dd>
<dt><i>mail</i></dt>
<dd>This utility was omitted in favor of <a href="../utilities/mailx.html"><i>mailx</i></a> because there was a considerable
functionality overlap between the two.</dd>
<dt><i>mknod</i></dt>
<dd>This was omitted in favor of <a href="../utilities/mkfifo.html"><i>mkfifo</i></a>, as <i>mknod</i> has too many
implementation-defined functions.</dd>
<dt><i>news</i></dt>
<dd>This utility is terminal-oriented and is not useful from shell scripts or typical application programs.</dd>
<dt><i>pack</i></dt>
<dd>This compression program was considered inferior to <a href="../utilities/compress.html"><i>compress</i></a>.</dd>
<dt><i>passwd</i></dt>
<dd>This utility was proposed in a historical draft of the base documents but met with too many objections to be included. There
were various reasons:
<ul>
<li>
<p>Changing a password should not be viewed as a command, but as part of the login sequence. Changing a password should only be
done while a trusted path is in effect.</p>
</li>
<li>
<p>Even though the text in early drafts was intended to allow a variety of implementations to conform, the security policy for one
site may differ from another site running with identical hardware and software. One site might use password authentication while
the other did not. Vendors could not supply a <i>passwd</i> utility that would conform to IEEE&nbsp;Std&nbsp;1003.1-2001 for all
sites using their system.</p>
</li>
<li>
<p>This is really a subject for a system administration working group or a security working group.</p>
</li>
</ul>
</dd>
<dt><i>pcat</i></dt>
<dd>This compression program was considered inferior to <a href="../utilities/zcat.html"><i>zcat</i></a>.</dd>
<dt><i>pg</i></dt>
<dd>This duplicated many of the features of the <a href="../utilities/more.html"><i>more</i></a> pager, which was preferred by the
standard developers.</dd>
<dt><i>prof</i></dt>
<dd>The intent of the various software development utilities was to assist in the installation (rather than the actual development
and debugging) of applications. This utility is primarily a debugging tool.</dd>
<dt>RCS</dt>
<dd>RCS was originally considered as part of a version control utilities portion of the scope. However, this aspect was abandoned
by the standard developers. SCCS is now included as an optional part of the XSI extension.</dd>
<dt><i>red</i></dt>
<dd>Restricted editor. This was not considered by the standard developers because it never provided the level of security
restriction required.</dd>
<dt><i>rsh</i></dt>
<dd>Restricted shell. This was not considered by the standard developers because it does not provide the level of security
restriction that is implied by historical documentation.</dd>
<dt><i>sdb</i></dt>
<dd>The intent of the various software development utilities was to assist in the installation (rather than the actual development
and debugging) of applications. This utility is primarily a debugging tool. Furthermore, some useful aspects of <i>sdb</i> are very
hardware-specific.</dd>
<dt><i>sdiff</i></dt>
<dd>The &quot;side-by-side <a href="../utilities/diff.html"><i>diff</i></a>&quot; utility from System&nbsp;V was omitted because it is used
infrequently, and even less so by conforming applications. Despite being in System&nbsp;V, it is not in the SVID or XPG.</dd>
<dt><i>shar</i></dt>
<dd>Any of the numerous &quot;shell archivers&quot; were excluded because they did not meet the requirement of existing practice.</dd>
<dt><i>shl</i></dt>
<dd>This utility is terminal-oriented and is not useful from shell scripts or typical application programs. The job control aspects
of the shell command language are generally more useful.</dd>
<dt><i>size</i></dt>
<dd>The intent of the various software development utilities was to assist in the installation (rather than the actual development
and debugging) of applications. This utility is primarily a debugging tool.</dd>
<dt><i>spell</i></dt>
<dd>This utility is not useful from shell scripts or typical application programs. The <i>spell</i> utility was considered, but was
omitted because there is no known technology that can be used to make it recognize general language for user-specified input
without providing a complete dictionary along with the input file.</dd>
<dt><i>su</i></dt>
<dd>This utility is not useful from shell scripts or typical application programs. (There was also sentiment to avoid
security-related utilities.)</dd>
<dt><i>sum</i></dt>
<dd>This utility was renamed <a href="../utilities/cksum.html"><i>cksum</i></a>.</dd>
<dt><i>tar</i></dt>
<dd>This has been replaced by <a href="../utilities/pax.html"><i>pax</i></a>, for reasons explained in the rationale for that
utility.</dd>
<dt><i>tsort</i></dt>
<dd>This utility is an aid in creating an implementation-defined detail of object libraries that the standard developers did not
feel required standardization.</dd>
<dt><i>unpack</i></dt>
<dd>This compression program was considered inferior to <a href="../utilities/uncompress.html"><i>uncompress</i></a>.</dd>
<dt><i>wall</i></dt>
<dd>This utility is terminal-oriented and is not useful in shell scripts or typical applications. It is generally used only by
system administrators.</dd>
</dl>
<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>

901
Ref-docs/POSIX/susv3/xrat/xsh_chap01.html Normal file
View File

@@ -0,0 +1,901 @@
<!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 System Interfaces</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 &copy; 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
<!--header end-->
<hr size="2" noshade>
<h2><a name="tag_03"></a>Rationale for System Interfaces</h2>
<h3><a name="tag_03_01"></a>Introduction</h3>
<h4><a name="tag_03_01_01"></a>Scope</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_01"><i>Scope</i></a> .</p>
<h4><a name="tag_03_01_02"></a>Conformance</h4>
<p>Refer to <a href="xbd_chap02.html#tag_01_02"><i>Conformance</i></a> .</p>
<h4><a name="tag_03_01_03"></a>Normative References</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_03_01_04"></a>Change History</h4>
<p>The change history is provided as an informative section, to track changes from previous issues of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
<p>The following sections describe changes made to the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001 since Issue 5 of
the base document. The CHANGE HISTORY section for each entry details the technical changes that have been made to that entry from
Issue 5. Changes between earlier issues of the base document and Issue 5 are not included.</p>
<p>The change history between Issue 5 and Issue 6 also lists the changes since the ISO&nbsp;POSIX-1:1996 standard.</p>
<h5><a name="tag_03_01_04_01"></a>Changes from Issue 5 to Issue 6 (IEEE&nbsp;Std&nbsp;1003.1-2001)</h5>
<p>The following list summarizes the major changes that were made in the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001
from Issue 5 to Issue 6:</p>
<ul>
<li>
<p>This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is extensively revised so that it can be both an IEEE POSIX Standard and an Open
Group Technical Standard.</p>
</li>
<li>
<p>The POSIX System Interfaces requirements incorporate support of FIPS 151-2.</p>
</li>
<li>
<p>The POSIX System Interfaces requirements are updated to align with some features of the Single UNIX Specification.</p>
</li>
<li>
<p>A RATIONALE section is added to each reference page.</p>
</li>
<li>
<p>Networking interfaces from the XNS, Issue 5.2 specification are incorporated.</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.1d-1999 is incorporated.</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.1j-2000 is incorporated.</p>
</li>
<li>
<p>IEEE&nbsp;Std&nbsp;1003.1q-2000 is incorporated.</p>
</li>
<li>
<p>IEEE&nbsp;P1003.1a draft standard is incorporated.</p>
</li>
<li>
<p>Existing functionality is aligned with the ISO/IEC&nbsp;9899:1999 standard.</p>
</li>
<li>
<p>New functionality from the ISO/IEC&nbsp;9899:1999 standard is incorporated.</p>
</li>
<li>
<p>IEEE PASC Interpretations are applied.</p>
</li>
<li>
<p>The Open Group corrigenda and resolutions are applied.</p>
</li>
</ul>
<h5><a name="tag_03_01_04_02"></a>New Features in Issue 6</h5>
<p>The functions first introduced in Issue 6 (over the Issue 5 Base document) are listed in the table below:</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="3" align="center">
<p class="tent"><b>New Functions in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../functions/acosf.html"><i>acosf</i>()</a><br>
<a href="../functions/acoshf.html"><i>acoshf</i>()</a><br>
<a href="../functions/acoshl.html"><i>acoshl</i>()</a><br>
<a href="../functions/acosl.html"><i>acosl</i>()</a><br>
<a href="../functions/asinf.html"><i>asinf</i>()</a><br>
<a href="../functions/asinhf.html"><i>asinhf</i>()</a><br>
<a href="../functions/asinhl.html"><i>asinhl</i>()</a><br>
<a href="../functions/asinl.html"><i>asinl</i>()</a><br>
<a href="../functions/atan2f.html"><i>atan2f</i>()</a><br>
<a href="../functions/atan2l.html"><i>atan2l</i>()</a><br>
<a href="../functions/atanf.html"><i>atanf</i>()</a><br>
<a href="../functions/atanhf.html"><i>atanhf</i>()</a><br>
<a href="../functions/atanhl.html"><i>atanhl</i>()</a><br>
<a href="../functions/atanl.html"><i>atanl</i>()</a><br>
<a href="../functions/atoll.html"><i>atoll</i>()</a><br>
<a href="../functions/cabs.html"><i>cabs</i>()</a><br>
<a href="../functions/cabsf.html"><i>cabsf</i>()</a><br>
<a href="../functions/cabsl.html"><i>cabsl</i>()</a><br>
<a href="../functions/cacos.html"><i>cacos</i>()</a><br>
<a href="../functions/cacosf.html"><i>cacosf</i>()</a><br>
<a href="../functions/cacosh.html"><i>cacosh</i>()</a><br>
<a href="../functions/cacoshf.html"><i>cacoshf</i>()</a><br>
<a href="../functions/cacoshl.html"><i>cacoshl</i>()</a><br>
<a href="../functions/cacosl.html"><i>cacosl</i>()</a><br>
<a href="../functions/carg.html"><i>carg</i>()</a><br>
<a href="../functions/cargf.html"><i>cargf</i>()</a><br>
<a href="../functions/cargl.html"><i>cargl</i>()</a><br>
<a href="../functions/casin.html"><i>casin</i>()</a><br>
<a href="../functions/casinf.html"><i>casinf</i>()</a><br>
<a href="../functions/casinh.html"><i>casinh</i>()</a><br>
<a href="../functions/casinhf.html"><i>casinhf</i>()</a><br>
<a href="../functions/casinhl.html"><i>casinhl</i>()</a><br>
<a href="../functions/casinl.html"><i>casinl</i>()</a><br>
<a href="../functions/catan.html"><i>catan</i>()</a><br>
<a href="../functions/catanf.html"><i>catanf</i>()</a><br>
<a href="../functions/catanh.html"><i>catanh</i>()</a><br>
<a href="../functions/catanhf.html"><i>catanhf</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/catanhl.html"><i>catanhl</i>()</a><br>
<a href="../functions/catanl.html"><i>catanl</i>()</a><br>
<a href="../functions/cbrtf.html"><i>cbrtf</i>()</a><br>
<a href="../functions/cbrtl.html"><i>cbrtl</i>()</a><br>
<a href="../functions/ccos.html"><i>ccos</i>()</a><br>
<a href="../functions/ccosf.html"><i>ccosf</i>()</a><br>
<a href="../functions/ccosh.html"><i>ccosh</i>()</a><br>
<a href="../functions/ccoshf.html"><i>ccoshf</i>()</a><br>
<a href="../functions/ccoshl.html"><i>ccoshl</i>()</a><br>
<a href="../functions/ccosl.html"><i>ccosl</i>()</a><br>
<a href="../functions/ceilf.html"><i>ceilf</i>()</a><br>
<a href="../functions/ceill.html"><i>ceill</i>()</a><br>
<a href="../functions/cexp.html"><i>cexp</i>()</a><br>
<a href="../functions/cexpf.html"><i>cexpf</i>()</a><br>
<a href="../functions/cexpl.html"><i>cexpl</i>()</a><br>
<a href="../functions/cimag.html"><i>cimag</i>()</a><br>
<a href="../functions/cimagf.html"><i>cimagf</i>()</a><br>
<a href="../functions/cimagl.html"><i>cimagl</i>()</a><br>
<a href="../functions/clock_getcpuclockid.html"><i>clock_getcpuclockid</i>()</a><br>
<a href="../functions/clock_nanosleep.html"><i>clock_nanosleep</i>()</a><br>
<a href="../functions/clog.html"><i>clog</i>()</a><br>
<a href="../functions/clogf.html"><i>clogf</i>()</a><br>
<a href="../functions/clogl.html"><i>clogl</i>()</a><br>
<a href="../functions/conj.html"><i>conj</i>()</a><br>
<a href="../functions/conjf.html"><i>conjf</i>()</a><br>
<a href="../functions/conjl.html"><i>conjl</i>()</a><br>
<a href="../functions/copysign.html"><i>copysign</i>()</a><br>
<a href="../functions/copysignf.html"><i>copysignf</i>()</a><br>
<a href="../functions/copysignl.html"><i>copysignl</i>()</a><br>
<a href="../functions/cosf.html"><i>cosf</i>()</a><br>
<a href="../functions/coshf.html"><i>coshf</i>()</a><br>
<a href="../functions/coshl.html"><i>coshl</i>()</a><br>
<a href="../functions/cosl.html"><i>cosl</i>()</a><br>
<a href="../functions/cpow.html"><i>cpow</i>()</a><br>
<a href="../functions/cpowf.html"><i>cpowf</i>()</a><br>
<a href="../functions/cpowl.html"><i>cpowl</i>()</a><br>
<a href="../functions/cproj.html"><i>cproj</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/cprojf.html"><i>cprojf</i>()</a><br>
<a href="../functions/cprojl.html"><i>cprojl</i>()</a><br>
<a href="../functions/creal.html"><i>creal</i>()</a><br>
<a href="../functions/crealf.html"><i>crealf</i>()</a><br>
<a href="../functions/creall.html"><i>creall</i>()</a><br>
<a href="../functions/csin.html"><i>csin</i>()</a><br>
<a href="../functions/csinf.html"><i>csinf</i>()</a><br>
<a href="../functions/csinh.html"><i>csinh</i>()</a><br>
<a href="../functions/csinhf.html"><i>csinhf</i>()</a><br>
<a href="../functions/csinhl.html"><i>csinhl</i>()</a><br>
<a href="../functions/csinl.html"><i>csinl</i>()</a><br>
<a href="../functions/csqrt.html"><i>csqrt</i>()</a><br>
<a href="../functions/csqrtf.html"><i>csqrtf</i>()</a><br>
<a href="../functions/csqrtl.html"><i>csqrtl</i>()</a><br>
<a href="../functions/ctan.html"><i>ctan</i>()</a><br>
<a href="../functions/ctanf.html"><i>ctanf</i>()</a><br>
<a href="../functions/ctanh.html"><i>ctanh</i>()</a><br>
<a href="../functions/ctanhf.html"><i>ctanhf</i>()</a><br>
<a href="../functions/ctanhl.html"><i>ctanhl</i>()</a><br>
<a href="../functions/ctanl.html"><i>ctanl</i>()</a><br>
<a href="../functions/erfcf.html"><i>erfcf</i>()</a><br>
<a href="../functions/erfcl.html"><i>erfcl</i>()</a><br>
<a href="../functions/erff.html"><i>erff</i>()</a><br>
<a href="../functions/erfl.html"><i>erfl</i>()</a><br>
<a href="../functions/exp2.html"><i>exp2</i>()</a><br>
<a href="../functions/exp2f.html"><i>exp2f</i>()</a><br>
<a href="../functions/exp2l.html"><i>exp2l</i>()</a><br>
<a href="../functions/expf.html"><i>expf</i>()</a><br>
<a href="../functions/expl.html"><i>expl</i>()</a><br>
<a href="../functions/expm1f.html"><i>expm1f</i>()</a><br>
<a href="../functions/expm1l.html"><i>expm1l</i>()</a><br>
<a href="../functions/fabsf.html"><i>fabsf</i>()</a><br>
<a href="../functions/fabsl.html"><i>fabsl</i>()</a><br>
<a href="../functions/fdim.html"><i>fdim</i>()</a><br>
<a href="../functions/fdimf.html"><i>fdimf</i>()</a><br>
<a href="../functions/fdiml.html"><i>fdiml</i>()</a><br>
<a href="../functions/feclearexcept.html"><i>feclearexcept</i>()</a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<hr>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="3" align="center">
<p class="tent"><b>New Functions in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../functions/fegetenv.html"><i>fegetenv</i>()</a><br>
<a href="../functions/fegetexceptflag.html"><i>fegetexceptflag</i>()</a><br>
<a href="../functions/fegetround.html"><i>fegetround</i>()</a><br>
<a href="../functions/feholdexcept.html"><i>feholdexcept</i>()</a><br>
<a href="../functions/feraiseexcept.html"><i>feraiseexcept</i>()</a><br>
<a href="../functions/fesetenv.html"><i>fesetenv</i>()</a><br>
<a href="../functions/fesetexceptflag.html"><i>fesetexceptflag</i>()</a><br>
<a href="../functions/fesetround.html"><i>fesetround</i>()</a><br>
<a href="../functions/fetestexcept.html"><i>fetestexcept</i>()</a><br>
<a href="../functions/feupdateenv.html"><i>feupdateenv</i>()</a><br>
<a href="../functions/floorf.html"><i>floorf</i>()</a><br>
<a href="../functions/floorl.html"><i>floorl</i>()</a><br>
<a href="../functions/fma.html"><i>fma</i>()</a><br>
<a href="../functions/fmaf.html"><i>fmaf</i>()</a><br>
<a href="../functions/fmal.html"><i>fmal</i>()</a><br>
<a href="../functions/fmax.html"><i>fmax</i>()</a><br>
<a href="../functions/fmaxf.html"><i>fmaxf</i>()</a><br>
<a href="../functions/fmaxl.html"><i>fmaxl</i>()</a><br>
<a href="../functions/fmin.html"><i>fmin</i>()</a><br>
<a href="../functions/fminf.html"><i>fminf</i>()</a><br>
<a href="../functions/fminl.html"><i>fminl</i>()</a><br>
<a href="../functions/fmodf.html"><i>fmodf</i>()</a><br>
<a href="../functions/fmodl.html"><i>fmodl</i>()</a><br>
<a href="../functions/fpclassify.html"><i>fpclassify</i>()</a><br>
<a href="../functions/frexpf.html"><i>frexpf</i>()</a><br>
<a href="../functions/frexpl.html"><i>frexpl</i>()</a><br>
<a href="../functions/hypotf.html"><i>hypotf</i>()</a><br>
<a href="../functions/hypotl.html"><i>hypotl</i>()</a><br>
<a href="../functions/ilogbf.html"><i>ilogbf</i>()</a><br>
<a href="../functions/ilogbl.html"><i>ilogbl</i>()</a><br>
<a href="../functions/imaxabs.html"><i>imaxabs</i>()</a><br>
<a href="../functions/imaxdiv.html"><i>imaxdiv</i>()</a><br>
<a href="../functions/isblank.html"><i>isblank</i>()</a><br>
<a href="../functions/isfinite.html"><i>isfinite</i>()</a><br>
<a href="../functions/isgreater.html"><i>isgreater</i>()</a><br>
<a href="../functions/isgreaterequal.html"><i>isgreaterequal</i>()</a><br>
<a href="../functions/isinf.html"><i>isinf</i>()</a><br>
<a href="../functions/isless.html"><i>isless</i>()</a><br>
<a href="../functions/islessequal.html"><i>islessequal</i>()</a><br>
<a href="../functions/islessgreater.html"><i>islessgreater</i>()</a><br>
<a href="../functions/isnormal.html"><i>isnormal</i>()</a><br>
<a href="../functions/isunordered.html"><i>isunordered</i>()</a><br>
<a href="../functions/iswblank.html"><i>iswblank</i>()</a><br>
<a href="../functions/ldexpf.html"><i>ldexpf</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/ldexpl.html"><i>ldexpl</i>()</a><br>
<a href="../functions/lgammaf.html"><i>lgammaf</i>()</a><br>
<a href="../functions/lgammal.html"><i>lgammal</i>()</a><br>
<a href="../functions/llabs.html"><i>llabs</i>()</a><br>
<a href="../functions/lldiv.html"><i>lldiv</i>()</a><br>
<a href="../functions/llrint.html"><i>llrint</i>()</a><br>
<a href="../functions/llrintf.html"><i>llrintf</i>()</a><br>
<a href="../functions/llrintl.html"><i>llrintl</i>()</a><br>
<a href="../functions/llround.html"><i>llround</i>()</a><br>
<a href="../functions/llroundf.html"><i>llroundf</i>()</a><br>
<a href="../functions/llroundl.html"><i>llroundl</i>()</a><br>
<a href="../functions/log10f.html"><i>log10f</i>()</a><br>
<a href="../functions/log10l.html"><i>log10l</i>()</a><br>
<a href="../functions/log1pf.html"><i>log1pf</i>()</a><br>
<a href="../functions/log1pl.html"><i>log1pl</i>()</a><br>
<a href="../functions/log2.html"><i>log2</i>()</a><br>
<a href="../functions/log2f.html"><i>log2f</i>()</a><br>
<a href="../functions/log2l.html"><i>log2l</i>()</a><br>
<a href="../functions/logbf.html"><i>logbf</i>()</a><br>
<a href="../functions/logbl.html"><i>logbl</i>()</a><br>
<a href="../functions/logf.html"><i>logf</i>()</a><br>
<a href="../functions/logl.html"><i>logl</i>()</a><br>
<a href="../functions/lrint.html"><i>lrint</i>()</a><br>
<a href="../functions/lrintf.html"><i>lrintf</i>()</a><br>
<a href="../functions/lrintl.html"><i>lrintl</i>()</a><br>
<a href="../functions/lround.html"><i>lround</i>()</a><br>
<a href="../functions/lroundf.html"><i>lroundf</i>()</a><br>
<a href="../functions/lroundl.html"><i>lroundl</i>()</a><br>
<a href="../functions/modff.html"><i>modff</i>()</a><br>
<a href="../functions/modfl.html"><i>modfl</i>()</a><br>
<a href="../functions/mq_timedreceive.html"><i>mq_timedreceive</i>()</a><br>
<a href="../functions/mq_timedsend.html"><i>mq_timedsend</i>()</a><br>
<a href="../functions/nan.html"><i>nan</i>()</a><br>
<a href="../functions/nanf.html"><i>nanf</i>()</a><br>
<a href="../functions/nanl.html"><i>nanl</i>()</a><br>
<a href="../functions/nearbyint.html"><i>nearbyint</i>()</a><br>
<a href="../functions/nearbyintf.html"><i>nearbyintf</i>()</a><br>
<a href="../functions/nearbyintl.html"><i>nearbyintl</i>()</a><br>
<a href="../functions/nextafterf.html"><i>nextafterf</i>()</a><br>
<a href="../functions/nextafterl.html"><i>nextafterl</i>()</a><br>
<a href="../functions/nexttoward.html"><i>nexttoward</i>()</a><br>
<a href="../functions/nexttowardf.html"><i>nexttowardf</i>()</a><br>
<a href="../functions/nexttowardl.html"><i>nexttowardl</i>()</a><br>
<a href="../functions/posix_fadvise.html"><i>posix_fadvise</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/posix_fallocate.html"><i>posix_fallocate</i>()</a><br>
<a href="../functions/posix_madvise.html"><i>posix_madvise</i>()</a><br>
<a href="../functions/posix_mem_offset.html"><i>posix_mem_offset</i>()</a><br>
<a href="../functions/posix_memalign.html"><i>posix_memalign</i>()</a><br>
<a href="../functions/posix_openpt.html"><i>posix_openpt</i>()</a><br>
<a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a><br>
<a href="../functions/posix_spawn_file_actions_addclose.html"><i>posix_spawn_file_actions_addclose</i>()</a><br>
<a href="../functions/posix_spawn_file_actions_adddup2.html"><i>posix_spawn_file_actions_adddup2</i>()</a><br>
<a href="../functions/posix_spawn_file_actions_addopen.html"><i>posix_spawn_file_actions_addopen</i>()</a><br>
<a href="../functions/posix_spawn_file_actions_destroy.html"><i>posix_spawn_file_actions_destroy</i>()</a><br>
<a href="../functions/posix_spawn_file_actions_init.html"><i>posix_spawn_file_actions_init</i>()</a><br>
<a href="../functions/posix_spawnattr_destroy.html"><i>posix_spawnattr_destroy</i>()</a><br>
<a href="../functions/posix_spawnattr_getflags.html"><i>posix_spawnattr_getflags</i>()</a><br>
<a href="../functions/posix_spawnattr_getpgroup.html"><i>posix_spawnattr_getpgroup</i>()</a><br>
<a href="../functions/posix_spawnattr_getschedparam.html"><i>posix_spawnattr_getschedparam</i>()</a><br>
<a href="../functions/posix_spawnattr_getschedpolicy.html"><i>posix_spawnattr_getschedpolicy</i>()</a><br>
<a href="../functions/posix_spawnattr_getsigdefault.html"><i>posix_spawnattr_getsigdefault</i>()</a><br>
<a href="../functions/posix_spawnattr_getsigmask.html"><i>posix_spawnattr_getsigmask</i>()</a><br>
<a href="../functions/posix_spawnattr_init.html"><i>posix_spawnattr_init</i>()</a><br>
<a href="../functions/posix_spawnattr_setflags.html"><i>posix_spawnattr_setflags</i>()</a><br>
<a href="../functions/posix_spawnattr_setpgroup.html"><i>posix_spawnattr_setpgroup</i>()</a><br>
<a href="../functions/posix_spawnattr_setschedparam.html"><i>posix_spawnattr_setschedparam</i>()</a><br>
<a href="../functions/posix_spawnattr_setschedpolicy.html"><i>posix_spawnattr_setschedpolicy</i>()</a><br>
<a href="../functions/posix_spawnattr_setsigdefault.html"><i>posix_spawnattr_setsigdefault</i>()</a><br>
<a href="../functions/posix_spawnattr_setsigmask.html"><i>posix_spawnattr_setsigmask</i>()</a><br>
<a href="../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a><br>
<a href="../functions/posix_trace_attr_destroy.html"><i>posix_trace_attr_destroy</i>()</a><br>
<a href="../functions/posix_trace_attr_getclockres.html"><i>posix_trace_attr_getclockres</i>()</a><br>
<a href="../functions/posix_trace_attr_getcreatetime.html"><i>posix_trace_attr_getcreatetime</i>()</a><br>
<a href="../functions/posix_trace_attr_getgenversion.html"><i>posix_trace_attr_getgenversion</i>()</a><br>
<a href="../functions/posix_trace_attr_getinherited.html"><i>posix_trace_attr_getinherited</i>()</a><br>
<a href="../functions/posix_trace_attr_getlogfullpolicy.html"><i>posix_trace_attr_getlogfullpolicy</i>()</a><br>
<a href="../functions/posix_trace_attr_getlogsize.html"><i>posix_trace_attr_getlogsize</i>()</a><br>
<a href="../functions/posix_trace_attr_getmaxdatasize.html"><i>posix_trace_attr_getmaxdatasize</i>()</a><br>
<a href="../functions/posix_trace_attr_getmaxsystemeventsize.html"><i>posix_trace_attr_getmaxsystemeventsize</i>()</a><br>
<a href="../functions/posix_trace_attr_getmaxusereventsize.html"><i>posix_trace_attr_getmaxusereventsize</i>()</a><br>
<a href="../functions/posix_trace_attr_getname.html"><i>posix_trace_attr_getname</i>()</a><br>
<a href="../functions/posix_trace_attr_getstreamfullpolicy.html"><i>posix_trace_attr_getstreamfullpolicy</i>()</a><br>
<a href="../functions/posix_trace_attr_getstreamsize.html"><i>posix_trace_attr_getstreamsize</i>()</a><br>
<a href="../functions/posix_trace_attr_init.html"><i>posix_trace_attr_init</i>()</a><br>
<a href="../functions/posix_trace_attr_setinherited.html"><i>posix_trace_attr_setinherited</i>()</a><br>
<a href="../functions/posix_trace_attr_setlogfullpolicy.html"><i>posix_trace_attr_setlogfullpolicy</i>()</a><br>
<a href="../functions/posix_trace_attr_setlogsize.html"><i>posix_trace_attr_setlogsize</i>()</a><br>
<a href="../functions/posix_trace_create.html"><i>posix_trace_create</i>()</a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<hr>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="3" align="center">
<p class="tent"><b>New Functions in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../functions/posix_trace_attr_setmaxdatasize.html"><i>posix_trace_attr_setmaxdatasize</i>()</a><br>
<a href="../functions/posix_trace_attr_setname.html"><i>posix_trace_attr_setname</i>()</a><br>
<a href="../functions/posix_trace_attr_setstreamfullpolicy.html"><i>posix_trace_attr_setstreamfullpolicy</i>()</a><br>
<a href="../functions/posix_trace_attr_setstreamsize.html"><i>posix_trace_attr_setstreamsize</i>()</a><br>
<a href="../functions/posix_trace_clear.html"><i>posix_trace_clear</i>()</a><br>
<a href="../functions/posix_trace_close.html"><i>posix_trace_close</i>()</a><br>
<a href="../functions/posix_trace_create_withlog.html"><i>posix_trace_create_withlog</i>()</a><br>
<a href="../functions/posix_trace_event.html"><i>posix_trace_event</i>()</a><br>
<a href="../functions/posix_trace_eventid_equal.html"><i>posix_trace_eventid_equal</i>()</a><br>
<a href="../functions/posix_trace_eventid_get_name.html"><i>posix_trace_eventid_get_name</i>()</a><br>
<a href="../functions/posix_trace_eventid_open.html"><i>posix_trace_eventid_open</i>()</a><br>
<a href="../functions/posix_trace_eventset_add.html"><i>posix_trace_eventset_add</i>()</a><br>
<a href="../functions/posix_trace_eventset_del.html"><i>posix_trace_eventset_del</i>()</a><br>
<a href="../functions/posix_trace_eventset_empty.html"><i>posix_trace_eventset_empty</i>()</a><br>
<a href="../functions/posix_trace_eventset_fill.html"><i>posix_trace_eventset_fill</i>()</a><br>
<a href="../functions/posix_trace_eventset_ismember.html"><i>posix_trace_eventset_ismember</i>()</a><br>
<a href="../functions/posix_trace_eventtypelist_getnext_id.html"><i>posix_trace_eventtypelist_getnext_id</i>()</a><br>
<a href="../functions/posix_trace_eventtypelist_rewind.html"><i>posix_trace_eventtypelist_rewind</i>()</a><br>
<a href="../functions/posix_trace_flush.html"><i>posix_trace_flush</i>()</a><br>
<a href="../functions/posix_trace_get_attr.html"><i>posix_trace_get_attr</i>()</a><br>
<a href="../functions/posix_trace_get_filter.html"><i>posix_trace_get_filter</i>()</a><br>
<a href="../functions/posix_trace_get_status.html"><i>posix_trace_get_status</i>()</a><br>
<a href="../functions/posix_trace_getnext_event.html"><i>posix_trace_getnext_event</i>()</a><br>
<a href="../functions/posix_trace_open.html"><i>posix_trace_open</i>()</a><br>
<a href="../functions/posix_trace_rewind.html"><i>posix_trace_rewind</i>()</a><br>
<a href="../functions/posix_trace_set_filter.html"><i>posix_trace_set_filter</i>()</a><br>
<a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a><br>
<a href="../functions/posix_trace_start.html"><i>posix_trace_start</i>()</a><br>
<a href="../functions/posix_trace_stop.html"><i>posix_trace_stop</i>()</a><br>
<a href="../functions/posix_trace_timedgetnext_event.html"><i>posix_trace_timedgetnext_event</i>()</a><br>
<a href="../functions/posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a><br>
<a href="../functions/posix_trace_trygetnext_event.html"><i>posix_trace_trygetnext_event</i>()</a><br>
<a href="../functions/posix_typed_mem_get_info.html"><i>posix_typed_mem_get_info</i>()</a><br>
<a href="../functions/posix_typed_mem_open.html"><i>posix_typed_mem_open</i>()</a><br>
<a href="../functions/powf.html"><i>powf</i>()</a><br>
<a href="../functions/powl.html"><i>powl</i>()</a><br>
<a href="../functions/pselect.html"><i>pselect</i>()</a><br>
<a href="../functions/pthread_attr_getstack.html"><i>pthread_attr_getstack</i>()</a><br>
<a href="../functions/pthread_attr_setstack.html"><i>pthread_attr_setstack</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/pthread_barrier_destroy.html"><i>pthread_barrier_destroy</i>()</a><br>
<a href="../functions/pthread_barrier_init.html"><i>pthread_barrier_init</i>()</a><br>
<a href="../functions/pthread_barrier_wait.html"><i>pthread_barrier_wait</i>()</a><br>
<a href="../functions/pthread_barrierattr_destroy.html"><i>pthread_barrierattr_destroy</i>()</a><br>
<a href="../functions/pthread_barrierattr_getpshared.html"><i>pthread_barrierattr_getpshared</i>()</a><br>
<a href="../functions/pthread_barrierattr_init.html"><i>pthread_barrierattr_init</i>()</a><br>
<a href="../functions/pthread_barrierattr_setpshared.html"><i>pthread_barrierattr_setpshared</i>()</a><br>
<a href="../functions/pthread_condattr_getclock.html"><i>pthread_condattr_getclock</i>()</a><br>
<a href="../functions/pthread_condattr_setclock.html"><i>pthread_condattr_setclock</i>()</a><br>
<a href="../functions/pthread_getcpuclockid.html"><i>pthread_getcpuclockid</i>()</a><br>
<a href="../functions/pthread_mutex_timedlock.html"><i>pthread_mutex_timedlock</i>()</a><br>
<a href="../functions/pthread_rwlock_timedrdlock.html"><i>pthread_rwlock_timedrdlock</i>()</a><br>
<a href="../functions/pthread_rwlock_timedwrlock.html"><i>pthread_rwlock_timedwrlock</i>()</a><br>
<a href="../functions/pthread_setschedprio.html"><i>pthread_setschedprio</i>()</a><br>
<a href="../functions/pthread_spin_destroy.html"><i>pthread_spin_destroy</i>()</a><br>
<a href="../functions/pthread_spin_init.html"><i>pthread_spin_init</i>()</a><br>
<a href="../functions/pthread_spin_lock.html"><i>pthread_spin_lock</i>()</a><br>
<a href="../functions/pthread_spin_trylock.html"><i>pthread_spin_trylock</i>()</a><br>
<a href="../functions/pthread_spin_unlock.html"><i>pthread_spin_unlock</i>()</a><br>
<a href="../functions/remainderf.html"><i>remainderf</i>()</a><br>
<a href="../functions/remainderl.html"><i>remainderl</i>()</a><br>
<a href="../functions/remquo.html"><i>remquo</i>()</a><br>
<a href="../functions/remquof.html"><i>remquof</i>()</a><br>
<a href="../functions/remquol.html"><i>remquol</i>()</a><br>
<a href="../functions/rintf.html"><i>rintf</i>()</a><br>
<a href="../functions/rintl.html"><i>rintl</i>()</a><br>
<a href="../functions/round.html"><i>round</i>()</a><br>
<a href="../functions/roundf.html"><i>roundf</i>()</a><br>
<a href="../functions/roundl.html"><i>roundl</i>()</a><br>
<a href="../functions/scalbln.html"><i>scalbln</i>()</a><br>
<a href="../functions/scalblnf.html"><i>scalblnf</i>()</a><br>
<a href="../functions/scalblnl.html"><i>scalblnl</i>()</a><br>
<a href="../functions/scalbn.html"><i>scalbn</i>()</a><br>
<a href="../functions/scalbnf.html"><i>scalbnf</i>()</a><br>
<a href="../functions/scalbnl.html"><i>scalbnl</i>()</a><br>
<a href="../functions/sem_timedwait.html"><i>sem_timedwait</i>()</a><br>
<a href="../functions/setegid.html"><i>setegid</i>()</a><br>
<a href="../functions/setenv.html"><i>setenv</i>()</a><br>
<a href="../functions/seteuid.html"><i>seteuid</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/signbit.html"><i>signbit</i>()</a><br>
<a href="../functions/sinf.html"><i>sinf</i>()</a><br>
<a href="../functions/sinhf.html"><i>sinhf</i>()</a><br>
<a href="../functions/sinhl.html"><i>sinhl</i>()</a><br>
<a href="../functions/sinl.html"><i>sinl</i>()</a><br>
<a href="../functions/sockatmark.html"><i>sockatmark</i>()</a><br>
<a href="../functions/sqrtf.html"><i>sqrtf</i>()</a><br>
<a href="../functions/sqrtl.html"><i>sqrtl</i>()</a><br>
<a href="../functions/strerror_r.html"><i>strerror_r</i>()</a><br>
<a href="../functions/strtoimax.html"><i>strtoimax</i>()</a><br>
<a href="../functions/strtoll.html"><i>strtoll</i>()</a><br>
<a href="../functions/strtoull.html"><i>strtoull</i>()</a><br>
<a href="../functions/strtoumax.html"><i>strtoumax</i>()</a><br>
<a href="../functions/tanf.html"><i>tanf</i>()</a><br>
<a href="../functions/tanhf.html"><i>tanhf</i>()</a><br>
<a href="../functions/tanhl.html"><i>tanhl</i>()</a><br>
<a href="../functions/tanl.html"><i>tanl</i>()</a><br>
<a href="../functions/tgamma.html"><i>tgamma</i>()</a><br>
<a href="../functions/tgammaf.html"><i>tgammaf</i>()</a><br>
<a href="../functions/tgammal.html"><i>tgammal</i>()</a><br>
<a href="../functions/trunc.html"><i>trunc</i>()</a><br>
<a href="../functions/truncf.html"><i>truncf</i>()</a><br>
<a href="../functions/truncl.html"><i>truncl</i>()</a><br>
<a href="../functions/unsetenv.html"><i>unsetenv</i>()</a><br>
<a href="../functions/vfprintf.html"><i>vfprintf</i>()</a><br>
<a href="../functions/vfscanf.html"><i>vfscanf</i>()</a><br>
<a href="../functions/vfwscanf.html"><i>vfwscanf</i>()</a><br>
<a href="../functions/vprintf.html"><i>vprintf</i>()</a><br>
<a href="../functions/vscanf.html"><i>vscanf</i>()</a><br>
<a href="../functions/vsnprintf.html"><i>vsnprintf</i>()</a><br>
<a href="../functions/vsprintf.html"><i>vsprintf</i>()</a><br>
<a href="../functions/vsscanf.html"><i>vsscanf</i>()</a><br>
<a href="../functions/vswscanf.html"><i>vswscanf</i>()</a><br>
<a href="../functions/vwscanf.html"><i>vwscanf</i>()</a><br>
<a href="../functions/wcstoimax.html"><i>wcstoimax</i>()</a><br>
<a href="../functions/wcstoll.html"><i>wcstoll</i>()</a><br>
<a href="../functions/wcstoull.html"><i>wcstoull</i>()</a><br>
<a href="../functions/wcstoumax.html"><i>wcstoumax</i>()</a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<p><br>
The following new headers are introduced in Issue 6:</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="3" align="center">
<p class="tent"><b>New Headers in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../basedefs/complex.h.html"><i>&lt;complex.h&gt;</i></a><br>
<a href="../basedefs/fenv.h.html"><i>&lt;fenv.h&gt;</i></a><br>
<a href="../basedefs/net/if.h.html"><i>&lt;net/if.h&gt;</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../basedefs/spawn.h.html"><i>&lt;spawn.h&gt;</i></a><br>
<a href="../basedefs/stdbool.h.html"><i>&lt;stdbool.h&gt;</i></a><br>
<a href="../basedefs/stdint.h.html"><i>&lt;stdint.h&gt;</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../basedefs/tgmath.h.html"><i>&lt;tgmath.h&gt;</i></a><br>
<a href="../basedefs/trace.h.html"><i>&lt;trace.h&gt;</i></a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<hr>
<p>The following table lists the functions and symbols from the XSI extension. These are new since the ISO&nbsp;POSIX-1:1996
standard.</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="4" align="center">
<p class="tent"><b>New XSI Functions and Symbols in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../functions/_longjmp.html"><i>_longjmp</i>()</a><br>
<a href="../functions/_setjmp.html"><i>_setjmp</i>()</a><br>
<a href="../functions/_tolower.html"><i>_tolower</i>()</a><br>
<a href="../functions/_toupper.html"><i>_toupper</i>()</a><br>
<a href="../functions/a64l.html"><i>a64l</i>()</a><br>
<a href="../functions/basename.html"><i>basename</i>()</a><br>
<a href="../functions/bcmp.html"><i>bcmp</i>()</a><br>
<a href="../functions/bcopy.html"><i>bcopy</i>()</a><br>
<a href="../functions/bzero.html"><i>bzero</i>()</a><br>
<a href="../functions/catclose.html"><i>catclose</i>()</a><br>
<a href="../functions/catgets.html"><i>catgets</i>()</a><br>
<a href="../functions/catopen.html"><i>catopen</i>()</a><br>
<a href="../functions/closelog.html"><i>closelog</i>()</a><br>
<a href="../functions/crypt.html"><i>crypt</i>()</a><br>
<i>daylight</i><br>
<a href="../functions/dbm_clearerr.html"><i>dbm_clearerr</i>()</a><br>
<a href="../functions/dbm_close.html"><i>dbm_close</i>()</a><br>
<a href="../functions/dbm_delete.html"><i>dbm_delete</i>()</a><br>
<a href="../functions/dbm_error.html"><i>dbm_error</i>()</a><br>
<a href="../functions/dbm_fetch.html"><i>dbm_fetch</i>()</a><br>
<a href="../functions/dbm_firstkey.html"><i>dbm_firstkey</i>()</a><br>
<a href="../functions/dbm_nextkey.html"><i>dbm_nextkey</i>()</a><br>
<a href="../functions/dbm_open.html"><i>dbm_open</i>()</a><br>
<a href="../functions/dbm_store.html"><i>dbm_store</i>()</a><br>
<a href="../functions/dirname.html"><i>dirname</i>()</a><br>
<a href="../functions/dlclose.html"><i>dlclose</i>()</a><br>
<a href="../functions/dlerror.html"><i>dlerror</i>()</a><br>
<a href="../functions/dlopen.html"><i>dlopen</i>()</a><br>
<a href="../functions/dlsym.html"><i>dlsym</i>()</a><br>
<a href="../functions/drand48.html"><i>drand48</i>()</a><br>
<a href="../functions/ecvt.html"><i>ecvt</i>()</a><br>
<a href="../functions/encrypt.html"><i>encrypt</i>()</a><br>
<a href="../functions/endgrent.html"><i>endgrent</i>()</a><br>
<a href="../functions/endpwent.html"><i>endpwent</i>()</a><br>
<a href="../functions/endutxent.html"><i>endutxent</i>()</a><br>
<a href="../functions/erand48.html"><i>erand48</i>()</a><br>
<a href="../functions/fchdir.html"><i>fchdir</i>()</a><br>
<a href="../functions/fcvt.html"><i>fcvt</i>()</a><br>
<a href="../functions/ffs.html"><i>ffs</i>()</a><br>
<a href="../functions/fmtmsg.html"><i>fmtmsg</i>()</a><br>
<a href="../functions/fstatvfs.html"><i>fstatvfs</i>()</a><br>
<a href="../functions/ftime.html"><i>ftime</i>()</a><br>
<a href="../functions/ftok.html"><i>ftok</i>()</a><br>
<a href="../functions/ftw.html"><i>ftw</i>()</a><br>
<a href="../functions/gcvt.html"><i>gcvt</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/getcontext.html"><i>getcontext</i>()</a><br>
<a href="../functions/getdate.html"><i>getdate</i>()</a><br>
<a href="../functions/getgrent.html"><i>getgrent</i>()</a><br>
<a href="../functions/gethostid.html"><i>gethostid</i>()</a><br>
<a href="../functions/getitimer.html"><i>getitimer</i>()</a><br>
<a href="../functions/getpgid.html"><i>getpgid</i>()</a><br>
<a href="../functions/getpmsg.html"><i>getpmsg</i>()</a><br>
<a href="../functions/getpriority.html"><i>getpriority</i>()</a><br>
<a href="../functions/getpwent.html"><i>getpwent</i>()</a><br>
<a href="../functions/getrlimit.html"><i>getrlimit</i>()</a><br>
<a href="../functions/getrusage.html"><i>getrusage</i>()</a><br>
<a href="../functions/getsid.html"><i>getsid</i>()</a><br>
<a href="../functions/getsubopt.html"><i>getsubopt</i>()</a><br>
<a href="../functions/gettimeofday.html"><i>gettimeofday</i>()</a><br>
<a href="../functions/getutxent.html"><i>getutxent</i>()</a><br>
<a href="../functions/getutxid.html"><i>getutxid</i>()</a><br>
<a href="../functions/getutxline.html"><i>getutxline</i>()</a><br>
<a href="../functions/getwd.html"><i>getwd</i>()</a><br>
<a href="../functions/grantpt.html"><i>grantpt</i>()</a><br>
<a href="../functions/hcreate.html"><i>hcreate</i>()</a><br>
<a href="../functions/hdestroy.html"><i>hdestroy</i>()</a><br>
<a href="../functions/hsearch.html"><i>hsearch</i>()</a><br>
<a href="../functions/iconv.html"><i>iconv</i>()</a><br>
<a href="../functions/iconv_close.html"><i>iconv_close</i>()</a><br>
<a href="../functions/iconv_open.html"><i>iconv_open</i>()</a><br>
<a href="../functions/index.html"><i>index</i>()</a><br>
<a href="../functions/initstate.html"><i>initstate</i>()</a><br>
<a href="../functions/insque.html"><i>insque</i>()</a><br>
<a href="../functions/isascii.html"><i>isascii</i>()</a><br>
<a href="../functions/jrand48.html"><i>jrand48</i>()</a><br>
<a href="../functions/killpg.html"><i>killpg</i>()</a><br>
<a href="../functions/l64a.html"><i>l64a</i>()</a><br>
<a href="../functions/lchown.html"><i>lchown</i>()</a><br>
<a href="../functions/lcong48.html"><i>lcong48</i>()</a><br>
<a href="../functions/lfind.html"><i>lfind</i>()</a><br>
<a href="../functions/lockf.html"><i>lockf</i>()</a><br>
<a href="../functions/lrand48.html"><i>lrand48</i>()</a><br>
<a href="../functions/lsearch.html"><i>lsearch</i>()</a><br>
<a href="../functions/makecontext.html"><i>makecontext</i>()</a><br>
<a href="../functions/memccpy.html"><i>memccpy</i>()</a><br>
<a href="../functions/mknod.html"><i>mknod</i>()</a><br>
<a href="../functions/mkstemp.html"><i>mkstemp</i>()</a><br>
<a href="../functions/mktemp.html"><i>mktemp</i>()</a><br>
<a href="../functions/mrand48.html"><i>mrand48</i>()</a><br>
<a href="../functions/msgctl.html"><i>msgctl</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/msgget.html"><i>msgget</i>()</a><br>
<a href="../functions/msgrcv.html"><i>msgrcv</i>()</a><br>
<a href="../functions/msgsnd.html"><i>msgsnd</i>()</a><br>
<a href="../functions/nftw.html"><i>nftw</i>()</a><br>
<a href="../functions/nice.html"><i>nice</i>()</a><br>
<a href="../functions/nl_langinfo.html"><i>nl_langinfo</i>()</a><br>
<a href="../functions/nrand48.html"><i>nrand48</i>()</a><br>
<a href="../functions/openlog.html"><i>openlog</i>()</a><br>
<a href="../functions/poll.html"><i>poll</i>()</a><br>
<a href="../functions/posix_openpt.html"><i>posix_openpt</i>()</a><br>
<a href="../functions/pread.html"><i>pread</i>()</a><br>
<a href="../functions/pthread_attr_getguardsize.html"><i>pthread_attr_getguardsize</i>()</a><br>
<a href="../functions/pthread_attr_setguardsize.html"><i>pthread_attr_setguardsize</i>()</a><br>
<a href="../functions/pthread_attr_setstack.html"><i>pthread_attr_setstack</i>()</a><br>
<a href="../functions/pthread_getconcurrency.html"><i>pthread_getconcurrency</i>()</a><br>
<a href="../functions/pthread_mutexattr_gettype.html"><i>pthread_mutexattr_gettype</i>()</a><br>
<a href="../functions/pthread_mutexattr_settype.html"><i>pthread_mutexattr_settype</i>()</a><br>
<a href="../functions/pthread_rwlockattr_init.html"><i>pthread_rwlockattr_init</i>()</a><br>
<a href="../functions/pthread_rwlockattr_setpshared.html"><i>pthread_rwlockattr_setpshared</i>()</a><br>
<a href="../functions/pthread_setconcurrency.html"><i>pthread_setconcurrency</i>()</a><br>
<a href="../functions/ptsname.html"><i>ptsname</i>()</a><br>
<a href="../functions/putenv.html"><i>putenv</i>()</a><br>
<a href="../functions/pututxline.html"><i>pututxline</i>()</a><br>
<a href="../functions/pwrite.html"><i>pwrite</i>()</a><br>
<a href="../functions/random.html"><i>random</i>()</a><br>
<a href="../functions/readv.html"><i>readv</i>()</a><br>
<a href="../functions/realpath.html"><i>realpath</i>()</a><br>
<a href="../functions/remque.html"><i>remque</i>()</a><br>
<a href="../functions/rindex.html"><i>rindex</i>()</a><br>
<a href="../functions/seed48.html"><i>seed48</i>()</a><br>
<a href="../functions/seekdir.html"><i>seekdir</i>()</a><br>
<a href="../functions/semctl.html"><i>semctl</i>()</a><br>
<a href="../functions/semget.html"><i>semget</i>()</a><br>
<a href="../functions/semop.html"><i>semop</i>()</a><br>
<a href="../functions/setcontext.html"><i>setcontext</i>()</a><br>
<a href="../functions/setgrent.html"><i>setgrent</i>()</a><br>
<a href="../functions/setitimer.html"><i>setitimer</i>()</a><br>
<a href="../functions/setkey.html"><i>setkey</i>()</a><br>
<a href="../functions/setlogmask.html"><i>setlogmask</i>()</a><br>
<a href="../functions/setpgrp.html"><i>setpgrp</i>()</a><br>
<a href="../functions/setpriority.html"><i>setpriority</i>()</a><br>
<a href="../functions/setpwent.html"><i>setpwent</i>()</a><br>
<a href="../functions/setregid.html"><i>setregid</i>()</a><br>
<a href="../functions/setreuid.html"><i>setreuid</i>()</a><br>
<a href="../functions/setrlimit.html"><i>setrlimit</i>()</a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../functions/setstate.html"><i>setstate</i>()</a><br>
<a href="../functions/setutxent.html"><i>setutxent</i>()</a><br>
<a href="../functions/shmat.html"><i>shmat</i>()</a><br>
<a href="../functions/shmctl.html"><i>shmctl</i>()</a><br>
<a href="../functions/shmdt.html"><i>shmdt</i>()</a><br>
<a href="../functions/shmget.html"><i>shmget</i>()</a><br>
<a href="../functions/sigaltstack.html"><i>sigaltstack</i>()</a><br>
<a href="../functions/sighold.html"><i>sighold</i>()</a><br>
<a href="../functions/sigignore.html"><i>sigignore</i>()</a><br>
<a href="../functions/siginterrupt.html"><i>siginterrupt</i>()</a><br>
<a href="../functions/sigpause.html"><i>sigpause</i>()</a><br>
<a href="../functions/sigrelse.html"><i>sigrelse</i>()</a><br>
<a href="../functions/sigset.html"><i>sigset</i>()</a><br>
<a href="../functions/srand48.html"><i>srand48</i>()</a><br>
<a href="../functions/srandom.html"><i>srandom</i>()</a><br>
<a href="../functions/statvfs.html"><i>statvfs</i>()</a><br>
<a href="../functions/strcasecmp.html"><i>strcasecmp</i>()</a><br>
<a href="../functions/strdup.html"><i>strdup</i>()</a><br>
<a href="../functions/strfmon.html"><i>strfmon</i>()</a><br>
<a href="../functions/strncasecmp.html"><i>strncasecmp</i>()</a><br>
<a href="../functions/strptime.html"><i>strptime</i>()</a><br>
<a href="../functions/swab.html"><i>swab</i>()</a><br>
<a href="../functions/swapcontext.html"><i>swapcontext</i>()</a><br>
<a href="../functions/sync.html"><i>sync</i>()</a><br>
<a href="../functions/syslog.html"><i>syslog</i>()</a><br>
<a href="../functions/tcgetsid.html"><i>tcgetsid</i>()</a><br>
<a href="../functions/tdelete.html"><i>tdelete</i>()</a><br>
<a href="../functions/telldir.html"><i>telldir</i>()</a><br>
<a href="../functions/tempnam.html"><i>tempnam</i>()</a><br>
<a href="../functions/tfind.html"><i>tfind</i>()</a><br>
<i>timezone</i><br>
<a href="../functions/toascii.html"><i>toascii</i>()</a><br>
<a href="../functions/truncate.html"><i>truncate</i>()</a><br>
<a href="../functions/tsearch.html"><i>tsearch</i>()</a><br>
<a href="../functions/twalk.html"><i>twalk</i>()</a><br>
<a href="../functions/ulimit.html"><i>ulimit</i>()</a><br>
<a href="../functions/unlockpt.html"><i>unlockpt</i>()</a><br>
<a href="../functions/utimes.html"><i>utimes</i>()</a><br>
<a href="../functions/waitid.html"><i>waitid</i>()</a><br>
<a href="../functions/wcswcs.html"><i>wcswcs</i>()</a><br>
<a href="../functions/wcswidth.html"><i>wcswidth</i>()</a><br>
<a href="../functions/wcwidth.html"><i>wcwidth</i>()</a><br>
<a href="../functions/writev.html"><i>writev</i>()</a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<br>
<p>The following table lists the headers from the XSI extension. These are new since the ISO&nbsp;POSIX-1:1996 standard.</p>
<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th colspan="3" align="center">
<p class="tent"><b>New XSI Headers in Issue 6</b></p>
</th>
</tr>
<tr valign="top">
<td align="left">
<p class="tent"><br>
<a href="../basedefs/cpio.h.html"><i>&lt;cpio.h&gt;</i></a><br>
<a href="../basedefs/dlfcn.h.html"><i>&lt;dlfcn.h&gt;</i></a><br>
<a href="../basedefs/fmtmsg.h.html"><i>&lt;fmtmsg.h&gt;</i></a><br>
<a href="../basedefs/ftw.h.html"><i>&lt;ftw.h&gt;</i></a><br>
<a href="../basedefs/iconv.h.html"><i>&lt;iconv.h&gt;</i></a><br>
<a href="../basedefs/langinfo.h.html"><i>&lt;langinfo.h&gt;</i></a><br>
<a href="../basedefs/libgen.h.html"><i>&lt;libgen.h&gt;</i></a><br>
<a href="../basedefs/monetary.h.html"><i>&lt;monetary.h&gt;</i></a><br>
<a href="../basedefs/ndbm.h.html"><i>&lt;ndbm.h&gt;</i></a><br>
<a href="../basedefs/nl_types.h.html"><i>&lt;nl_types.h&gt;</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../basedefs/poll.h.html"><i>&lt;poll.h&gt;</i></a><br>
<a href="../basedefs/search.h.html"><i>&lt;search.h&gt;</i></a><br>
<a href="../basedefs/strings.h.html"><i>&lt;strings.h&gt;</i></a><br>
<a href="../basedefs/stropts.h.html"><i>&lt;stropts.h&gt;</i></a><br>
<a href="../basedefs/sys/ipc.h.html"><i>&lt;sys/ipc.h&gt;</i></a><br>
<a href="../basedefs/sys/mman.h.html"><i>&lt;sys/mman.h&gt;</i></a><br>
<a href="../basedefs/sys/msg.h.html"><i>&lt;sys/msg.h&gt;</i></a><br>
<a href="../basedefs/sys/resource.h.html"><i>&lt;sys/resource.h&gt;</i></a><br>
<a href="../basedefs/sys/sem.h.html"><i>&lt;sys/sem.h&gt;</i></a><br>
<a href="../basedefs/sys/shm.h.html"><i>&lt;sys/shm.h&gt;</i></a><br>
&nbsp;</p>
</td>
<td align="left">
<p class="tent"><br>
<a href="../basedefs/sys/statvfs.h.html"><i>&lt;sys/statvfs.h&gt;</i></a><br>
<a href="../basedefs/sys/time.h.html"><i>&lt;sys/time.h&gt;</i></a><br>
<a href="../basedefs/sys/timeb.h.html"><i>&lt;sys/timeb.h&gt;</i></a><br>
<a href="../basedefs/sys/uio.h.html"><i>&lt;sys/uio.h&gt;</i></a><br>
<a href="../basedefs/syslog.h.html"><i>&lt;syslog.h&gt;</i></a><br>
<a href="../basedefs/ucontext.h.html"><i>&lt;ucontext.h&gt;</i></a><br>
<a href="../basedefs/ulimit.h.html"><i>&lt;ulimit.h&gt;</i></a><br>
<a href="../basedefs/utmpx.h.html"><i>&lt;utmpx.h&gt;</i></a><br>
&nbsp;</p>
</td>
</tr>
</table>
</center>
<h4><a name="tag_03_01_05"></a>Terminology</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_04"><i>Terminology</i></a> .</p>
<h4><a name="tag_03_01_06"></a>Definitions</h4>
<p>Refer to <a href="xbd_chap03.html#tag_01_03"><i>Definitions</i></a> .</p>
<h4><a name="tag_03_01_07"></a>Relationship to Other Formal Standards</h4>
<p>There is no additional rationale provided for this section.</p>
<h4><a name="tag_03_01_08"></a>Portability</h4>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_18"><i>Portability</i></a> .</p>
<h5><a name="tag_03_01_08_01"></a>Codes</h5>
<p>Refer to <a href="xbd_chap01.html#tag_01_01_18_01"><i>Codes</i></a> .</p>
<h4><a name="tag_03_01_09"></a>Format of Entries</h4>
<p>Each system interface reference page has a common layout of sections describing the interface. This layout is similar to the
manual page or &quot;man&quot; page format shipped with most UNIX systems, and each header has sections describing the SYNOPSIS,
DESCRIPTION, RETURN VALUE, and ERRORS. These are the four sections that relate to conformance.</p>
<p>Additional sections are informative, and add considerable information for the application developer. EXAMPLES sections provide
example usage. APPLICATION USAGE sections provide additional caveats, issues, and recommendations to the developer. RATIONALE
sections give additional information on the decisions made in defining the interface.</p>
<p>FUTURE DIRECTIONS sections act as pointers to related work that may impact the interface in the future, and often cautions the
developer to architect the code to account for a change in this area. Note that a future directions statement should not be taken
as a commitment to adopt a feature or interface in the future.</p>
<p>The CHANGE HISTORY section describes when the interface was introduced, and how it has changed.</p>
<p>Option labels and margin markings in the page can be useful in guiding the application developer.</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>

7229
Ref-docs/POSIX/susv3/xrat/xsh_chap02.html Normal file
View File

File diff suppressed because it is too large Load Diff

554
Ref-docs/POSIX/susv3/xrat/xsh_chap03.html Normal file
View File

@@ -0,0 +1,554 @@
<!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</title>
</head>
<body>
<basefont size="3">
<center><font size="2">The Open Group Base Specifications Issue 6<br>
IEEE Std 1003.1-2001<br>
Copyright &copy; 2001 The IEEE and The Open Group</font></center>
<hr size="2" noshade>
<h3><a name="tag_03_03"></a>System Interfaces</h3>
<p>See the RATIONALE sections on the individual reference pages.</p>
<h4><a name="tag_03_03_01"></a>Examples for Spawn</h4>
<p>The following long examples are provided in the Rationale (Informative) volume of IEEE&nbsp;Std&nbsp;1003.1-2001 as a supplement
to the reference page for <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a>.</p>
<h5><a name="tag_03_03_01_01"></a>Example Library Implementation of Spawn</h5>
<p>The <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> or <a href=
"../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a> functions provide the following:</p>
<ul>
<li>
<p>Simply start a process executing a process image. This is the simplest application for process creation, and it may cover most
executions of <a href="../functions/fork.html"><i>fork</i>()</a>.</p>
</li>
<li>
<p>Support I/O redirection, including pipes.</p>
</li>
<li>
<p>Run the child under a user and group ID in the domain of the parent.</p>
</li>
<li>
<p>Run the child at any priority in the domain of the parent.</p>
</li>
</ul>
<p>The <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> or <a href=
"../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a> functions do not cover every possible use of the <a href=
"../functions/fork.html"><i>fork</i>()</a> function, but they do span the common applications: typical use by a shell and a login
utility.</p>
<p>The price for an application is that before it calls <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> or <a
href="../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a>, the parent must adjust to a state that <a href=
"../functions/posix_spawn.html"><i>posix_spawn</i>()</a> or <a href="../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a> can
map to the desired state for the child. Environment changes require the parent to save some of its state and restore it afterwards.
The effective behavior of a successful invocation of <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> is as if the
operation were implemented with POSIX operations as follows:</p>
<pre>
<tt>#include &lt;sys/types.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;stdio.h&gt;
#include &lt;unistd.h&gt;
#include &lt;sched.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;signal.h&gt;
#include &lt;errno.h&gt;
#include &lt;string.h&gt;
#include &lt;signal.h&gt;
<br>
/* #include &lt;spawn.h&gt; */
/*******************************************/
/* Things that could be defined in spawn.h */
/*******************************************/
typedef struct
{
short posix_attr_flags;
#define POSIX_SPAWN_SETPGROUP 0x1
#define POSIX_SPAWN_SETSIGMASK 0x2
#define POSIX_SPAWN_SETSIGDEF 0x4
#define POSIX_SPAWN_SETSCHEDULER 0x8
#define POSIX_SPAWN_SETSCHEDPARAM 0x10
#define POSIX_SPAWN_RESETIDS 0x20
pid_t posix_attr_pgroup;
sigset_t posix_attr_sigmask;
sigset_t posix_attr_sigdefault;
int posix_attr_schedpolicy;
struct sched_param posix_attr_schedparam;
} posix_spawnattr_t;
<br>
typedef char *posix_spawn_file_actions_t;
<br>
int posix_spawn_file_actions_init(
posix_spawn_file_actions_t *file_actions);
int posix_spawn_file_actions_destroy(
posix_spawn_file_actions_t *file_actions);
int posix_spawn_file_actions_addclose(
posix_spawn_file_actions_t *file_actions, int fildes);
int posix_spawn_file_actions_adddup2(
posix_spawn_file_actions_t *file_actions, int fildes,
int newfildes);
int posix_spawn_file_actions_addopen(
posix_spawn_file_actions_t *file_actions, int fildes,
const char *path, int oflag, mode_t mode);
int posix_spawnattr_init(posix_spawnattr_t *attr);
int posix_spawnattr_destroy(posix_spawnattr_t *attr);
int posix_spawnattr_getflags(const posix_spawnattr_t *attr,
short *lags);
int posix_spawnattr_setflags(posix_spawnattr_t *attr, short flags);
int posix_spawnattr_getpgroup(const posix_spawnattr_t *attr,
pid_t *pgroup);
int posix_spawnattr_setpgroup(posix_spawnattr_t *attr, pid_t pgroup);
int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *attr,
int *schedpolicy);
int posix_spawnattr_setschedpolicy(posix_spawnattr_t *attr,
int schedpolicy);
int posix_spawnattr_getschedparam(const posix_spawnattr_t *attr,
struct sched_param *schedparam);
int posix_spawnattr_setschedparam(posix_spawnattr_t *attr,
const struct sched_param *schedparam);
int posix_spawnattr_getsigmask(const posix_spawnattr_t *attr,
sigset_t *sigmask);
int posix_spawnattr_setsigmask(posix_spawnattr_t *attr,
const sigset_t *sigmask);
int posix_spawnattr_getdefault(const posix_spawnattr_t *attr,
sigset_t *sigdefault);
int posix_spawnattr_setsigdefault(posix_spawnattr_t *attr,
const sigset_t *sigdefault);
int posix_spawn(pid_t *pid, const char *path,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *attrp, char *const argv[],
char *const envp[]);
int posix_spawnp(pid_t *pid, const char *file,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *attrp, char *const argv[],
char *const envp[]);
<br>
/*****************************************/
/* Example posix_spawn() library routine */
/*****************************************/
int posix_spawn(pid_t *pid,
const char *path,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *attrp,
char *const argv[],
char *const envp[])
{
/* Create process */
if ((*pid = fork()) == (pid_t) 0)
{
/* This is the child process */
/* Worry about process group */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_SETPGROUP)
{
/* Override inherited process group */
if (setpgid(0, attrp-&gt;posix_attr_pgroup) != 0)
{
/* Failed */
exit(127);
}
}
<br>
/* Worry about process signal mask */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_SETSIGMASK)
{
/* Set the signal mask (can't fail) */
sigprocmask(SIG_SETMASK, &amp;attrp-&gt;posix_attr_sigmask, NULL);
}
<br>
/* Worry about resetting effective user and group IDs */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_RESETIDS)
{
/* None of these can fail for this case. */
setuid(getuid());
setgid(getgid());
}
<br>
/* Worry about defaulted signals */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_SETSIGDEF)
{
struct sigaction deflt;
sigset_t all_signals;
<br>
int s;
<br>
/* Construct default signal action */
deflt.sa_handler = SIG_DFL;
deflt.sa_flags = 0;
<br>
/* Construct the set of all signals */
sigfillset(&amp;all_signals);
<br>
/* Loop for all signals */
for (s = 0; sigismember(&amp;all_signals, s); s++)
{
/* Signal to be defaulted? */
if (sigismember(&amp;attrp-&gt;posix_attr_sigdefault, s))
{
/* Yes; default this signal */
if (sigaction(s, &amp;deflt, NULL) == -1)
{
/* Failed */
exit(127);
}
}
}
}
<br>
/* Worry about the fds if they are to be mapped */
if (file_actions != NULL)
{
/* Loop for all actions in object file_actions */
/* (implementation dives beneath abstraction) */
char *p = *file_actions;
<br>
while (*p != '\0')
{
if (strncmp(p, "close(", 6) == 0)
{
int fd;
<br>
if (sscanf(p + 6, "%d)", &amp;fd) != 1)
{
exit(127);
}
if (close(fd) == -1)
exit(127);
}
else if (strncmp(p, "dup2(", 5) == 0)
{
int fd, newfd;
<br>
if (sscanf(p + 5, "%d,%d)", &amp;fd, &amp;newfd) != 2)
{
exit(127);
}
if (dup2(fd, newfd) == -1)
exit(127);
}
else if (strncmp(p, "open(", 5) == 0)
{
int fd, oflag;
mode_t mode;
int tempfd;
char path[1000]; /* Should be dynamic */
char *q;
<br>
if (sscanf(p + 5, "%d,", &amp;fd) != 1)
{
exit(127);
}
p = strchr(p, ',') + 1;
q = strchr(p, '*');
if (q == NULL)
exit(127);
strncpy(path, p, q - p);
path[q - p] = '\0';
if (sscanf(q + 1, "%o,%o)", &amp;oflag, &amp;mode) != 2)
{
exit(127);
}
if (close(fd) == -1)
{
if (errno != EBADF)
exit(127);
}
tempfd = open(path, oflag, mode);
if (tempfd == -1)
exit(127);
if (tempfd != fd)
{
if (dup2(tempfd, fd) == -1)
{
exit(127);
}
if (close(tempfd) == -1)
{
exit(127);
}
}
}
else
{
exit(127);
}
p = strchr(p, ')') + 1;
}
}
<br>
/* Worry about setting new scheduling policy and parameters */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_SETSCHEDULER)
{
if (sched_setscheduler(0, attrp-&gt;posix_attr_schedpolicy,
&amp;attrp-&gt;posix_attr_schedparam) == -1)
{
exit(127);
}
}
<br>
/* Worry about setting only new scheduling parameters */
if (attrp-&gt;posix_attr_flags &amp; POSIX_SPAWN_SETSCHEDPARAM)
{
if (sched_setparam(0, &amp;attrp-&gt;posix_attr_schedparam) == -1)
{
exit(127);
}
}
<br>
/* Now execute the program at path */
/* Any fd that still has FD_CLOEXEC set will be closed */
execve(path, argv, envp);
exit(127); /* exec failed */
}
else
{
/* This is the parent (calling) process */
if (*pid == (pid_t) - 1)
return errno;
return 0;
}
}
<br>
/*******************************************************/
/* Here is a crude but effective implementation of the */
/* file action object operators which store actions as */
/* concatenated token-separated strings. */
/*******************************************************/
/* Create object with no actions. */
int posix_spawn_file_actions_init(
posix_spawn_file_actions_t *file_actions)
{
*file_actions = malloc(sizeof(char));
if (*file_actions == NULL)
return ENOMEM;
strcpy(*file_actions, "");
return 0;
}
<br>
/* Free object storage and make invalid. */
int posix_spawn_file_actions_destroy(
posix_spawn_file_actions_t *file_actions)
{
free(*file_actions);
*file_actions = NULL;
return 0;
}
<br>
/* Add a new action string to object. */
static int add_to_file_actions(
posix_spawn_file_actions_t *file_actions, char *new_action)
{
*file_actions = realloc
(*file_actions, strlen(*file_actions) + strlen(new_action) + 1);
if (*file_actions == NULL)
return ENOMEM;
strcat(*file_actions, new_action);
return 0;
}
<br>
/* Add a close action to object. */
int posix_spawn_file_actions_addclose(
posix_spawn_file_actions_t *file_actions, int fildes)
{
char temp[100];
<br>
sprintf(temp, "close(%d)", fildes);
return add_to_file_actions(file_actions, temp);
}
<br>
/* Add a dup2 action to object. */
int posix_spawn_file_actions_adddup2(
posix_spawn_file_actions_t *file_actions, int fildes,
int newfildes)
{
char temp[100];
<br>
sprintf(temp, "dup2(%d,%d)", fildes, newfildes);
return add_to_file_actions(file_actions, temp);
}
<br>
/* Add an open action to object. */
int posix_spawn_file_actions_addopen(
posix_spawn_file_actions_t *file_actions, int fildes,
const char *path, int oflag, mode_t mode)
{
char temp[100];
<br>
sprintf(temp, "open(%d,%s*%o,%o)", fildes, path, oflag, mode);
return add_to_file_actions(file_actions, temp);
}
<br>
/*******************************************************/
/* Here is a crude but effective implementation of the */
/* spawn attributes object functions which manipulate */
/* the individual attributes. */
/*******************************************************/
/* Initialize object with default values. */
int posix_spawnattr_init(posix_spawnattr_t *attr)
{
attr-&gt;posix_attr_flags = 0;
attr-&gt;posix_attr_pgroup = 0;
/* Default value of signal mask is the parent's signal mask; */
/* other values are also allowed */
sigprocmask(0, NULL, &amp;attr-&gt;posix_attr_sigmask);
sigemptyset(&amp;attr-&gt;posix_attr_sigdefault);
/* Default values of scheduling attr inherited from the parent; */
/* other values are also allowed */
attr-&gt;posix_attr_schedpolicy = sched_getscheduler(0);
sched_getparam(0, &amp;attr-&gt;posix_attr_schedparam);
return 0;
}
<br>
int posix_spawnattr_destroy(posix_spawnattr_t *attr)
{
/* No action needed */
return 0;
}
<br>
int posix_spawnattr_getflags(const posix_spawnattr_t *attr,
short *flags)
{
*flags = attr-&gt;posix_attr_flags;
return 0;
}
<br>
int posix_spawnattr_setflags(posix_spawnattr_t *attr, short flags)
{
attr-&gt;posix_attr_flags = flags;
return 0;
}
<br>
int posix_spawnattr_getpgroup(const posix_spawnattr_t *attr,
pid_t *pgroup)
{
*pgroup = attr-&gt;posix_attr_pgroup;
return 0;
}
<br>
int posix_spawnattr_setpgroup(posix_spawnattr_t *attr, pid_t pgroup)
{
attr-&gt;posix_attr_pgroup = pgroup;
return 0;
}
<br>
int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *attr,
int *schedpolicy)
{
*schedpolicy = attr-&gt;posix_attr_schedpolicy;
return 0;
}
<br>
int posix_spawnattr_setschedpolicy(posix_spawnattr_t *attr,
int schedpolicy)
{
attr-&gt;posix_attr_schedpolicy = schedpolicy;
return 0;
}
<br>
int posix_spawnattr_getschedparam(const posix_spawnattr_t *attr,
struct sched_param *schedparam)
{
*schedparam = attr-&gt;posix_attr_schedparam;
return 0;
}
<br>
int posix_spawnattr_setschedparam(posix_spawnattr_t *attr,
const struct sched_param *schedparam)
{
attr-&gt;posix_attr_schedparam = *schedparam;
return 0;
}
<br>
int posix_spawnattr_getsigmask(const posix_spawnattr_t *attr,
sigset_t *sigmask)
{
*sigmask = attr-&gt;posix_attr_sigmask;
return 0;
}
<br>
int posix_spawnattr_setsigmask(posix_spawnattr_t *attr,
const sigset_t *sigmask)
{
attr-&gt;posix_attr_sigmask = *sigmask;
return 0;
}
<br>
int posix_spawnattr_getsigdefault(const posix_spawnattr_t *attr,
sigset_t *sigdefault)
{
*sigdefault = attr-&gt;posix_attr_sigdefault;
return 0;
}
<br>
int posix_spawnattr_setsigdefault(posix_spawnattr_t *attr,
const sigset_t *sigdefault)
{
attr-&gt;posix_attr_sigdefault = *sigdefault;
return 0;
}
</tt>
</pre>
<h5><a name="tag_03_03_01_02"></a>I/O Redirection with Spawn</h5>
<p>I/O redirection with <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> or <a href=
"../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a> is accomplished by crafting a <i>file_actions</i> argument to effect the
desired redirection. Such a redirection follows the general outline of the following example:</p>
<pre>
<tt>/* To redirect new standard output (fd 1) to a file, */
/* and redirect new standard input (fd 0) from my fd socket_pair[1], */
/* and close my fd socket_pair[0] in the new process. */
posix_spawn_file_actions_t file_actions;
posix_spawn_file_actions_init(&amp;file_actions);
posix_spawn_file_actions_addopen(&amp;file_actions, 1, "newout", ...);
posix_spawn_file_actions_dup2(&amp;file_actions, socket_pair[1], 0);
posix_spawn_file_actions_close(&amp;file_actions, socket_pair[0]);
posix_spawn_file_actions_close(&amp;file_actions, socket_pair[1]);
posix_spawn(..., &amp;file_actions, ...);
posix_spawn_file_actions_destroy(&amp;file_actions);
</tt>
</pre>
<h5><a name="tag_03_03_01_03"></a>Spawning a Process Under a New User ID</h5>
<p>Spawning a process under a new user ID follows the outline shown in the following example:</p>
<pre>
<tt>Save = getuid();
setuid(newid);
posix_spawn(...);
setuid(Save);
</tt>
</pre>
<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>