📄 xsh_chap02.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy, see www.w3.org"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 --><!-- Copyright (c) 2001-2003 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, 2003 Edition<br>Copyright © 2001-2003 The IEEE and The Open Group</font></center><hr size="2" noshade><h3><a name="tag_03_02"></a>General Information</h3><h4><a name="tag_03_02_01"></a>Use and Implementation of Functions</h4><p>The information concerning the use of functions was adapted from a description in the ISO C standard. Here is an example ofhow an application program can protect itself from functions that may or may not be macros, rather than true functions:</p><p>The <a href="../functions/atoi.html"><i>atoi</i>()</a> function may be used in any of several ways:</p><ul><li><p>By use of its associated header (possibly generating a macro expansion):</p><blockquote><pre><tt>#include <stdlib.h>/* ... */i = atoi(str);</tt></pre></blockquote></li><li><p>By use of its associated header (assuredly generating a true function call):</p><blockquote><pre><tt>#include <stdlib.h>#undef atoi/* ... */i = atoi(str);</tt></pre></blockquote><p>or:</p><blockquote><pre><tt>#include <stdlib.h>/* ... */i = (atoi) (str);</tt></pre></blockquote></li><li><p>By explicit declaration:</p><blockquote><pre><tt>extern int atoi (const char *);/* ... */i = atoi(str);</tt></pre></blockquote></li><li><p>By implicit declaration:</p><blockquote><pre><tt>/* ... */i = atoi(str);</tt></pre></blockquote><p>(Assuming no function prototype is in scope. This is not allowed by the ISO C standard for functions with variablearguments; furthermore, parameter type conversion "widening" is subject to different rules in this case.)</p></li></ul><p>Note that the ISO C standard reserves names starting with <tt>'_'</tt> for the compiler. Therefore, the compiler could, forexample, implement an intrinsic, built-in function <i>_asm_builtin_atoi</i>(), which it recognized and expanded into inlineassembly code. Then, in <a href="../basedefs/stdlib.h.html"><i><stdlib.h></i></a>, there could be the following:</p><blockquote><pre><tt>#define atoi(X) _asm_builtin_atoi(X)</tt></pre></blockquote><p>The user's "normal" call to <a href="../functions/atoi.html"><i>atoi</i>()</a> would then be expanded inline, but theimplementor would also be required to provide a callable function named <a href="../functions/atoi.html"><i>atoi</i>()</a> for usewhen the application requires it; for example, if its address is to be stored in a function pointer variable.</p><h4><a name="tag_03_02_02"></a>The Compilation Environment</h4><h5><a name="tag_03_02_02_01"></a>POSIX.1 Symbols</h5><p>This and the following section address the issue of "name space pollution". The ISO C standard requires that the namespace beyond what it reserves not be altered except by explicit action of the application writer. This section defines the actionsto add the POSIX.1 symbols for those headers where both the ISO C standard and POSIX.1 need to define symbols, and also wherethe XSI extension extends the base standard.</p><p>When headers are used to provide symbols, there is a potential for introducing symbols that the application writer cannotpredict. Ideally, each header should only contain one set of symbols, but this is not practical for historical reasons. Thus, theconcept of feature test macros is included. Two feature test macros are explicitly defined by IEEE Std 1003.1-2001; it isexpected that future revisions may add to this. <basefont size="2"></p><dl><dt><b>Note:</b></dt><dd>Feature test macros allow an application to announce to the implementation its desire to have certain symbols and prototypesexposed. They should not be confused with the version test macros and constants for options in <a href="../basedefs/unistd.h.html"><i><unistd.h></i></a> which are the implementation's way of announcing functionality to theapplication.</dd></dl><basefont size="3"> <p>It is further intended that these feature test macros apply only to the headers specified by IEEE Std 1003.1-2001.Implementations are expressly permitted to make visible symbols not specified by IEEE Std 1003.1-2001, within bothPOSIX.1 and other headers, under the control of feature test macros that are not defined by IEEE Std 1003.1-2001.</p><h5><a name="tag_03_02_02_02"></a>The _POSIX_C_SOURCE Feature Test Macro</h5><p>Since _POSIX_SOURCE specified by the POSIX.1-1990 standard did not have a value associated with it, the _POSIX_C_SOURCE macroreplaces it, allowing an application to inform the system of the revision of the standard to which it conforms. This symbol willallow implementations to support various revisions of IEEE Std 1003.1-2001 simultaneously. For instance, when either_POSIX_SOURCE is defined or _POSIX_C_SOURCE is defined as 1, the system should make visible the same name space as permitted andrequired by the POSIX.1-1990 standard. When _POSIX_C_SOURCE is defined, the state of _POSIX_SOURCE is completely irrelevant.</p><p>It is expected that C bindings to future POSIX standards will define new values for _POSIX_C_SOURCE, with each new valuereserving the name space for that new standard, plus all earlier POSIX standards.</p><h5><a name="tag_03_02_02_03"></a>The _XOPEN_SOURCE Feature Test Macro</h5><p>The feature test macro _XOPEN_SOURCE is provided as the announcement mechanism for the application that it requiresfunctionality from the Single UNIX Specification. _XOPEN_SOURCE must be defined to the value 600 before the inclusion of any headerto enable the functionality in the Single UNIX Specification. Its definition subsumes the use of _POSIX_SOURCE and_POSIX_C_SOURCE.</p><p>An extract of code from a conforming application, that appears before any <b>#include</b> statements, is given below:</p><pre><tt>#define _XOPEN_SOURCE 600 /* Single UNIX Specification, Version 3 */<br>#include ...</tt></pre><p>Note that the definition of _XOPEN_SOURCE with the value 600 makes the definition of _POSIX_C_SOURCE redundant and it can safelybe omitted.</p><h5><a name="tag_03_02_02_04"></a>The Name Space</h5><p>The reservation of identifiers is paraphrased from the ISO C standard. The text is included because it needs to be part ofIEEE Std 1003.1-2001, regardless of possible changes in future versions of the ISO C standard.</p><p>These identifiers may be used by implementations, particularly for feature test macros. Implementations should not use featuretest macro names that might be reasonably used by a standard.</p><p>Including headers more than once is a reasonably common practice, and it should be carried forward from the ISO C standard.More significantly, having definitions in more than one header is explicitly permitted. Where the potential declaration is"benign" (the same definition twice) the declaration can be repeated, if that is permitted by the compiler. (This is usually trueof macros, for example.) In those situations where a repetition is not benign (for example, <b>typedef</b>s), conditionalcompilation must be used. The situation actually occurs both within the ISO C standard and within POSIX.1: <b>time_t</b>should be in <a href="../basedefs/sys/types.h.html"><i><sys/types.h></i></a>, and the ISO C standard mandates that it bein <a href="../basedefs/time.h.html"><i><time.h></i></a>.</p><p>The area of name space pollution <i>versus</i> additions to structures is difficult because of the macro structure of C. Thefollowing discussion summarizes all the various problems with and objections to the issue.</p><p>Note the phrase "user-defined macro". Users are not permitted to define macro names (or any other name) beginning with<tt>"_[A-Z_]"</tt> . Thus, the conflict cannot occur for symbols reserved to the vendor's name space, and the permission to addfields automatically applies, without qualification, to those symbols.</p><ol><li><p>Data structures (and unions) need to be defined in headers by implementations to meet certain requirements of POSIX.1 and theISO C standard.</p></li><li><p>The structures defined by POSIX.1 are typically minimal, and any practical implementation would wish to add fields to thesestructures either to hold additional related information or for backwards-compatibility (or both). Future standards (and <i>defacto</i> standards) would also wish to add to these structures. Issues of field alignment make it impractical (at least in thegeneral case) to simply omit fields when they are not defined by the particular standard involved.</p><p>The <b>dirent</b> structure is an example of such a minimal structure (although one could argue about whether the other fieldsneed visible names). The <i>st_rdev</i> field of most implementations' <b>stat</b> structure is a common example where extension isneeded and where a conflict could occur.</p></li>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -