xsh_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

<li>
<p>Fields in structures are in an independent name space, so the addition of such fields presents no problem to the C language
itself in that such names cannot interact with identically named user symbols because access is qualified by the specific structure
name.</p>
</li>

<li>
<p>There is an exception to this: macro processing is done at a lexical level. Thus, symbols added to a structure might be
recognized as user-provided macro names at the location where the structure is declared. This only can occur if the user-provided
name is declared as a macro before the header declaring the structure is included. The user's use of the name after the declaration
cannot interfere with the structure because the symbol is hidden and only accessible through access to the structure. Presumably,
the user would not declare such a macro if there was an intention to use that field name.</p>
</li>

<li>
<p>Macros from the same or a related header might use the additional fields in the structure, and those field names might also
collide with user macros. Although this is a less frequent occurrence, since macros are expanded at the point of use, no constraint
on the order of use of names can apply.</p>
</li>

<li>
<p>An &quot;obvious&quot; solution of using names in the reserved name space and then redefining them as macros when they should be visible
does not work because this has the effect of exporting the symbol into the general name space. For example, given a (hypothetical)
system-provided header <i>&lt;h.h&gt;</i>, and two parts of a C program in <b>a.c</b> and <b>b.c</b>, in header
<i>&lt;h.h&gt;</i>:</p>

<blockquote>
<pre>
<tt>struct foo {
    int __i;
}
<br>
#ifdef _FEATURE_TEST
#define i __i;
#endif
</tt>
</pre>
</blockquote>

<p>In file <b>a.c</b>:</p>

<blockquote>
<pre>
<tt>#include h.h
extern int i;
...
</tt>
</pre>
</blockquote>

<p>In file <b>b.c</b>:</p>

<blockquote>
<pre>
<tt>extern int i;
...
</tt>
</pre>
</blockquote>

<p>The symbol that the user thinks of as <i>i</i> in both files has an external name of <i>__i</i> in <b>a.c</b>; the same symbol
<i>i</i> in <b>b.c</b> has an external name <i>i</i> (ignoring any hidden manipulations the compiler might perform on the names).
This would cause a mysterious name resolution problem when <b>a.o</b> and <b>b.o</b> are linked.</p>

<p>Simply avoiding definition then causes alignment problems in the structure.</p>

<p>A structure of the form:</p>

<blockquote>
<pre>
<tt>struct foo {
    union {
        int __i;
#ifdef _FEATURE_TEST
        int i;
#endif
    } __ii;
}
</tt>
</pre>
</blockquote>

<p>does not work because the name of the logical field <i>i</i> is <i>__ii.i</i>, and introduction of a macro to restore the
logical name immediately reintroduces the problem discussed previously (although its manifestation might be more immediate because
a syntax error would result if a recursive macro did not cause it to fail first).</p>
</li>

<li>
<p>A more workable solution would be to declare the structure:</p>

<blockquote>
<pre>
<tt>struct foo {
#ifdef _FEATURE_TEST
    int i;
#else
    int __i;
#endif
}
</tt>
</pre>
</blockquote>

<p>However, if a macro (particularly one required by a standard) is to be defined that uses this field, two must be defined: one
that uses <i>i</i>, the other that uses <i>__i</i>. If more than one additional field is used in a macro and they are conditional
on distinct combinations of features, the complexity goes up as 2<small><sup><i>n</i></sup></small>.</p>
</li>
</ol>

<p>All this leaves a difficult situation: vendors must provide very complex headers to deal with what is conceptually simple and
safe-adding a field to a structure. It is the possibility of user-provided macros with the same name that makes this difficult.</p>

<p>Several alternatives were proposed that involved constraining the user's access to part of the name space available to the user
(as specified by the ISO&nbsp;C standard). In some cases, this was only until all the headers had been included. There were two
proposals discussed that failed to achieve consensus:</p>

<ol>
<li>
<p>Limiting it for the whole program.</p>
</li>

<li>
<p>Restricting the use of identifiers containing only uppercase letters until after all system headers had been included. It was
also pointed out that because macros might wish to access fields of a structure (and macro expansion occurs totally at point of
use) restricting names in this way would not protect the macro expansion, and thus the solution was inadequate.</p>
</li>
</ol>

<p>It was finally decided that reservation of symbols would occur, but as constrained.</p>

<p>The current wording also allows the addition of fields to a structure, but requires that user macros of the same name not
interfere. This allows vendors to do one of the following:</p>

<ul>
<li>
<p>Not create the situation (do not extend the structures with user-accessible names or use the solution in (7) above)</p>
</li>

<li>
<p>Extend their compilers to allow some way of adding names to structures and macros safely</p>
</li>
</ul>

<p>There are at least two ways that the compiler might be extended: add new preprocessor directives that turn off and on macro
expansion for certain symbols (without changing the value of the macro) and a function or lexical operation that suppresses
expansion of a word. The latter seems more flexible, particularly because it addresses the problem in macros as well as in
declarations.</p>

<p>The following seems to be a possible implementation extension to the C language that will do this: any token that during macro
expansion is found to be preceded by three <tt>'#'</tt> symbols shall not be further expanded in exactly the same way as described
for macros that expand to their own name as in Section 3.8.3.4 of the ISO&nbsp;C standard. A vendor may also wish to implement this
as an operation that is lexically a function, which might be implemented as:</p>

<blockquote>
<pre>
<tt>#define __safe_name(x) ###x
</tt>
</pre>
</blockquote>

<p>Using a function notation would insulate vendors from changes in standards until such a functionality is standardized (if ever).
Standardization of such a function would be valuable because it would then permit third parties to take advantage of it portably in
software they may supply.</p>

<p>The symbols that are &quot;explicitly permitted, but not required by IEEE&nbsp;Std&nbsp;1003.1-2001&quot; include those classified
below. (That is, the symbols classified below might, but are not required to, be present when _POSIX_C_SOURCE is defined to have
the value 200112L.)</p>

<ul>
<li>
<p>Symbols 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> that are defined to indicate support for options or limits that are
constant at compile-time</p>
</li>

<li>
<p>Symbols in the name space reserved for the implementation by the ISO&nbsp;C standard</p>
</li>

<li>
<p>Symbols in a name space reserved for a particular type of extension (for example, type names ending with <b>_t</b> in <a href=
"../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a>)</p>
</li>

<li>
<p>Additional members of structures or unions whose names do not reduce the name space reserved for applications</p>
</li>
</ul>

<p>Since both implementations and future revisions of IEEE&nbsp;Std&nbsp;1003.1 and other POSIX standards may use symbols in the
reserved spaces described in these tables, there is a potential for name space clashes. To avoid future name space clashes when
adding symbols, implementations should not use the posix_, POSIX_, or _POSIX_ prefixes.</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/2 is applied, deleting the entries POSIX_, _POSIX_, and posix_ from
the column of allowed name space prefixes for use by an implementation in the first table. The presence of these prefixes was
contradicting later text which states that: &quot;The prefixes posix_, POSIX_, and _POSIX are reserved for use by Shell and Utilities
volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html">Chapter 2, Shell Command Language</a> and other
POSIX standards. Implementations may add symbols to the headers shown in the following table, provided the identifiers ... do not
use the reserved prefixes posix_, POSIX_, or _POSIX.&quot;.</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/3 is applied, correcting the reserved macro prefix from: &quot;PRI[a-z],
SCN[a-z]&quot; to: &quot;PRI[Xa-z], SCN[Xa-z]&quot; in the second table. The change was needed since the ISO&nbsp;C standard allows
implementations to define macros of the form PRI or SCN followed by any lowercase letter or <tt>'X'</tt> in <a href=
"../basedefs/inttypes.h.html"><i>&lt;inttypes.h&gt;</i></a>. (The ISO/IEC&nbsp;9899:1999 standard, Subclause 7.26.4.)</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/4 is applied, adding a new section listing reserved names for the <a
href="../basedefs/stdint.h.html"><i>&lt;stdint.h&gt;</i></a> header. This change is for alignment with the ISO&nbsp;C standard.</p>

<h4><a name="tag_03_02_03"></a>Error Numbers</h4>