Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!longway!std-unix
From: gwyn@brl.arpa (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-ID: <428@longway.TIC.COM>
Date: 15 Nov 89 23:47:02 GMT
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 49
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: gwyn@brl.arpa (Doug Gwyn)

In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (Chuck Karish) writes:
>According to Section 2.8.2.1 of the 1003.1 document, "If there are no
>feature test macros present in a program, only the set of symbols
>defined by the C standard shall be present".  This means that the
>symbols may be present, but they must be concealed by a feature test
>macro:

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.

>A header that conforms to POSIX 1003.1 as well as to the SVID and
>X/OPEN standards will be a bit complicated.  A SVID-conforming program
>that doesn't use POSIX extensions will expect UNIX identifiers to be
>visible in the headers without use of a feature test macro.

That's true, but it's easily accomplished: the implementation merely
needs to provide separate ways of invoking the compiler for POSIX/ANSI_C
and "traditional" UNIX environments, in the latter case predefining some
feature-test macro used to enable "traditional" extensions in the
standard headers.  Of course the feature-test macro used for this must
be in the name space reserved for implementations.

>Section 2.2.4 says "Any invocation of a library function that is
>implemented as a macro shall expand to code that evaluates each of its
>arguments only once ...".  However, WIFSIGNALED is defined in the
>Standard as a macro, not as a library function.  It's legal to
>evaluate these arguments twice; maybe not wise but, strictly
>speaking, legal.

Again, that depends on how one interprets the wording.  Just because
the spec requires that a particular "library function" be implemented
as a macro does not keep it from being a library function implemented
as a macro!  (And therefore subject to IEEE 1003.1 2.2.4.)  You can't
argue that "library function" means genuine C function as opposed to
function-like macro, either, because if that were a valid interpretation
what would be the point of 2.2.4 talking about "library function that is
implemented as a macro"?  I think the sanest interpretation is that even
the things specifically stated in the spec to be (function-like) macros
must be implemented to evaluate each of their arguments only once per
macro invocation.  Thus, the WIFSIGNALED implementation you cited would
be non-POSIX in that respect.

Perhaps the 1003.1 working group should clarify this along with the
other post-publication changes they have planned.

Volume-Number: Volume 17, Number 57