Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.20/text0133.txt

Internet Message Format | 1990-08-02 | 3.2 KB

From:  Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>>From the 1003.1 standard, 2.8.2:
>    Symbols called `feature test macros' are used to control the
>    visibility of symbols that might be included in a header.
>    Implementations, future versions of this standard, and other
>    standards may define additional feature test macros.
>My interpretation of this text is that the 1003.1 committee wanted to
>provide a mechanism by which a number of standards and implementations
>could share the C namespace.

The feature-test macro provision was the outcome of discussions among
DOnn Terry, Dave Prosser, myself, and a few others in an attempt to
resolve the problem that a single implementation could not simultaneously
conform to IEEE Std 1003.1 and ANS X3.159 due to the strict prohibition
of the latter against implementations defining or declaring non-reserved
identifiers in the standard headers.  Because of the evolutionary history
of the standard headers, some of them contained both UNIX-specific and
OS-independent definitions/declarations; for example, <stdio.h> included
fopen(), which applies in every hosted C environment, and fdopen(), which
is relevant only for UNIX-like environments.  Partly out of legitimate
political concerns, X3J11 refused to allow any special dispensation for
UNIX-specific extensions in the standard C headers, and as a generally
appreciated service to C programmers everywhere forbid conforming C
implementations to add other (non-reserved, i.e. not starting with
underscore etc.) identifiers to the standard headers.  Thus, in effect
other standards such as POSIX, if they are to be compatible with the C
language standard, must not require implementations to define/declare
such names in the headers specified in X3.159.  Yet, P1003 wished to add
some of the traditional UNIX identifiers to those headers.  This is the
problem that the feature-test macro POSIX_SOURCE was intended to solve.
(X3J11 recommended a similar but functionally different solution.)  While
they were at it, P1003 decided that packages other than 1003.1 might also
benefit from feature-test macros, and ended up with the wording you saw.

The technical loophole is that any application that defines _POSIX_SOURCE
has violated a constraint of X3.159, by using a reserved identifier, and
this allows the implementation to act in a non-X3.159-conforming manner,
in this case to define/declare otherwise-prohibited identifiers.

One drawback is that any portable 1003.1-based application that uses any
of the 1003.1 extensions in standard headers will have to predefine the
feature-test macro before including the headers.

There is no such problem with inclusion of headers NOT specified in
X3.159.  Thus, feature-test macros can be avoided simply by specifying
that new facilities be defined/declared in new add-on headers.  This is
much more convenient for the programmer and is highly recommended.
There is no historical-evolutionary problem for new POSIX standards,
and thus there is no need for a mechanism to share the standard headers
for new standards.  Instead of trying to add more cruft to standard C
headers, new inventions should provide their own headers.


Volume-Number: Volume 20, Number 131