Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!brutus.cs.uiuc.edu!apple!agate!shelby!portia!forel!karish
From: karish@forel.stanford.edu (Chuck Karish)
Newsgroups: comp.unix.questions
Subject: Re: Some questions about POSIX headers
Summary: Some corrections
Message-ID: <6649@portia.Stanford.EDU>
Date: 14 Nov 89 18:22:44 GMT
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Followup-To: comp.std.unix
Organization: Mindcraft, Inc.
Lines: 67

As I expected when I answered these questions yesterday, there were
some subtleties I hadn't appreciated.  Doug Gwyn pointed some of them
out in another answer, but he didn't get them all, either.

In article <6622@portia.Stanford.EDU> karish@forel.stanford.edu
(Chuck Karish) wrote:
>In article <4508@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) wrote:
>>I have several questions about POSIX P1003.1.  Consider the following
>>excerpt from <sys/wait.h>:
>>#define _LOW(__v)               ( (__v) & 0377)
>>#define _HIGH(__v)              ( ((__v) >> 8) & 0377)
>>#define WIFSIGNALED(__s)	(_HIGH(__s) == 0 && __s != 0) /* signaled */
>
>>1. Is it legal to have _LOW and _HIGH here (name space pollution rules)?

>    These identifiers are OK with file scope or smaller inside a C
>    library implementation, but not as external identifiers.


[ Doug said that _LOW and _HIGH are OK in a header. ]

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:

#ifdef	_C_LIBRARY
#define _LOW(__v)               ( (__v) & 0377)
#define _HIGH(__v)              ( ((__v) >> 8) & 0377)
#endif

Any program that wants to use them must #define that feature
test macro before the header is #included.  There may be a number
of feature test macros in effect.  Each one makes visible a
specific set of identifiers.  Identifiers specified by 1003.1
are to be visible only if the _POSIX_SOURCE macro is #defined
before the header is #included.  Note that this macro should
have been called _POSIX1_SOURCE; other macros will be used for
other POSIX standards.

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.

>>3. WIFSIGNALED evaluates __s twice.  Is this legal?  In an ANSI C header
>>   it is specifically forbidden.  What about POSIX?
>
>    Explicitly forbidden.  Section 2.2.4.

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.

>>4. Is the extra set of parenthesis around __v in _HIGH() really required?
>    No.  `>>' has higher precedence than `&'.

Doug says `yes', and he's right.  If __v is an expression that includes
an operator with lower precedence than `&', there will be trouble
if the parentheses are omitted.

	Chuck Karish		karish@mindcraft.com
	(415) 323-9000		karish@forel.stanford.edu