Path: utzoo!attcan!uunet!cs.utexas.edu!longway!std-unix
From: karish@forel.stanford.edu (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-ID: <434@longway.TIC.COM>
Date: 20 Nov 89 20:17:54 GMT
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> <428@longway.TIC.COM> <431@longway.TIC.COM> <432@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Lines: 56
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: karish@forel.stanford.edu (Chuck Karish)

In article <432@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
>In article <431@longway.TIC.COM> karish@forel.stanford.edu
(Chuck Karish) writes:
>-In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
>->No, it doesn't -- because "the set of symbols defined by the C standard"
>->can, and must, be construed as permitting all symbols that the C standard
>->specifically reserves for the implementation, including _LOW etc.
>-To me, "the set of symbols defined by the C standard" means the set of
>-symbols defined, not the set of all possible symbols in some part of
>-the name space.  I interpreted this to mean the set of symbols listed
>-in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard).  "Defined"
>-and "reserved" denote different concepts.
>
>But IEEE Std 1003.1 cannot constrain the identifiers reserved for
>implementation use by ANSI X3.159.  

Agreed.

>The intention of this part of
>the 1003.1 spec is quite clear -- it means that applications cannot
>count on the symbols defined by 1003.1 as being visible in the
>Standard C headers unless _POSIX_SOURCE is defined before including
>the headers.  It does not impose additional constraints on the pure
>X3.159 part of the implementation.

If the intention were "quite clear" as expressed in the document, this
thread wouldn't exist.

The relevant sentence from 1003.1 is: "If there are no feature test
macros present in a program, only the set of symbols defined by the C
standard shall be present".  From this wording, the reader has no
immediate way to tell that the set of allowed symbols is what's meant,
rather than the specific symbols required by the C standard; that
"defined" modifies "set", not "symbols".  This ambiguity has led
some readers of 1003.1 to look in the C standard for a list of defined
symbols, and to find Appendix 3.  Under this interpretation, 1003.1
excludes implementation-defined symbols from the standard headers.

>You are being deliberately obtuse.

It's my job to be obtuse in cases like this, and it's yours, too.  It's
neither unusual nor unexpected that people involved with writing a
complicated document miss some of the ambiguities it contains.  It is
sometimes necessary to affect a naive attitude in order to foresee how
one's words might be misinterpreted.  In this case, no such cupidity
was necessary.  The wording really is confusing.

Note that I said in my first posting on this question that I was basing
my answer on a literal reading of the relevant documents.  If the
reader needs to have special knowledge or to note every subtle nuance
of meaning in order to understand a standard, the standard is
inadequate.

Volume-Number: Volume 17, Number 62