Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!jbc
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Message-ID: <10116@cs.utexas.edu>
Date: 14 Jul 90 19:37:46 GMT
References: <9951@cs.utexas.edu> <9997@cs.utexas.edu> <10059@cs.utexas.edu>
Sender: jbc@cs.utexas.edu
Reply-To: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 57
Approved: jbc@cs.utexas.edu (Guest Moderator, John B. Chambers)

From:  Doug Gwyn <gwyn@smoke.brl.mil>


In article <10059@cs.utexas.edu> std-unix@uunet.uu.net 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