Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jbc
From: karish@mindcrf.uucp
Newsgroups: comp.std.unix
Subject: Re: _POSIX_1_SOURCE (was: Standards Update, IEEE 1003.1: System services)interface
Summary: Say NO to feature test macro proliferation
Message-ID: <10059@cs.utexas.edu>
Date: 13 Jul 90 21:07:17 GMT
References: <9951@cs.utexas.edu> <9997@cs.utexas.edu>
Sender: jbc@cs.utexas.edu
Reply-To: std-unix@uunet.uu.net
Organization: Mindcraft, Inc.
Lines: 63
Approved: jbc@cs.utexas.edu (Guest Moderator, John B. Chambers)

From:  karish@mindcrf.uucp


In article <9997@cs.utexas.edu> std-unix@uunet.uu.net writes:
>From:  jms@apple.com (John Michael Sovereign)
>In article <9951@cs.utexas.edu> jason@cnd.hp.com (Jason Zions) writes:
>
>> This makes the assumption that there is indeed a single POSIX name space,
>> to which pieces are added by the various working groups. This assumption,
>> while a reasonable one, is in fact not correct.
>
>There is, however, a single C language name space which new standards (and 
>revisions)
>pollute as long as they continue to use header files already defined by 
>ANSI C and/or POSIX.1
>(as I believe Doug Gwyn pointed out recently).

>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.  Of course, extended use of this mechanism
is up to the other standards committees and implementors, and is
outside the scope of 1003.1.  Perhaps this is an issue that Dot 0
could help clear up.

>> The various 1003.* working groups are *not* developing separate 
>components
>> of an overall, integrated POSIX standard. Each POSIX standard stands 
>alone....

Which makes it essential that each standard specify what it assumes
is available from its host, and what it will add to the composite
environment.  While each standard may stand alone, implementations
certainly won't.

>As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing 
>_POSIX_SOURCE
>can't be used (perhaps modified) for this purpose.

Because, unlike __STDC__, _POSIX_SOURCE is #defined or not #defined;
its value is not significant.  The implication of the suggestion to use
_POSIX_1_SOURCE for 1003.1a-conforming headers is that the 1003.1
committee is reserving for its own use all feature test macro names
that start with _POSIX_.  This means that the 1003.2 committee will be
on shaky ground if they require that programmers #define
_POSIX_2_SOURCE in order to make 1003.2 symbols visible.

The approach chosen by the ANSI C committee was a good one:  Use a single
name for the feature test macro, and change the macro's VALUE when a
new version of the standard supersedes an old one.
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000		


Volume-Number: Volume 20, Number 124