Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!longway!std-unix
From: johnz@grapevine.EBay.Sun.COM (John Zolnowsky ext. 33230)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Summary: _POSIX_n_SOURCE, a source of confusion?
Message-ID: <803@longway.TIC.COM>
Date: 9 Jul 90 17:50:35 GMT
References: <385@usenix.ORG>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 47
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From:  johnz@grapevine.EBay.Sun.COM (John Zolnowsky ext. 33230)

In article <385@usenix.ORG>, jsh@usenix.org writes:
> Paul Rabin <rabin@osf.org> reports on the April 23-27 meeting in Salt
> Lake City, UT:
> 
> 3.3  Headers and Name-Space Control
> 
> A new feature-test macro will be specified by 1003.1b and subsequent
> revisions: _POSIX_1_SOURCE.  This macro takes ordinal values, starting
> with 2 for 1003.1b, and will be incremented by 1 for every subsequent
> revision.  If the value is 1, the effect will be the same as if
> _POSIX_SOURCE were defined.
> 
> There are two changes here.  The new name was used to indicate that
> the macro only controls the visibility of identifiers defined in
> POSIX.1.  The usage was changed to allow the value to indicate the
> particular revision or supplement to the standard, rather than having
> to create a new macro each time.  This should simplify the
> construction and maintenance of header files.

I recognize that programs must have some way of freezing the
ever-growing POSIX namespace, but I have reservations about the
approach implicit in the name _POSIX_1_SOURCE.

I suspect that the "1" in _POSIX_n_SOURCE refers to 1003.1, as a
working group or a standard.  This creates a strictly historical
binding between a function name and the working group which first
needed to define an interface, and this binding will be perpetuated in
code.  As an example, imagine the goobledeegook when multi-threaded
network servers must tree-walk and want to be cognizant of symlinks.

Since it is planned that all these standards will be unified under the
umbrella of ISO 9945-1 (or whatever future number the C-binding appears
unders) it would seem more prudent to have a single feature-test macro,
such as _POSIX_C_SOURCE, for which for increasing values expose the
entire POSIX function namespace in historical order.  This would place
no further requirements upon implementations.  Applications would be
affected only when being modified to use POSIX extensions:  they would
then have to honor not only the namespace reservation of the extension,
but of all of POSIX at the time the extension was standardized.  Note
that this requirement already exists for any other interfaces added by
the working group which added the extension.

-John Zolnowsky         johnz@EBay.Sun.COM              (408)276-3230

Volume-Number: Volume 20, Number 117