Path: utzoo!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: 1003.1 refers to ANSI C
Message-ID: <6622@portia.Stanford.EDU>
Date: 14 Nov 89 03:22:33 GMT
References: <4508@ast.cs.vu.nl>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Lines: 69

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 WIFEXITED(__s)		(_LOW(__s) == 0)	      /* normal exit */
>#define WEXITSTATUS(__s)	(_HIGH(__s))	 	      /* exit status */
>#define WTERMSIG(__s)		(_LOW(__s) & 0177)	      /* sig value */
>#define WIFSIGNALED(__s)	(_HIGH(__s) == 0 && __s != 0) /* signaled */

>1. Is it legal to have _LOW and _HIGH here (name space pollution rules)?
>2. Are the parameters __s and __v required to begin with __ (again, name
>   space pollution rules)?

    [ CAVEAT:  I've read what I believe to be the relevant parts of
    the 1003.1 standard and the May, 1988 X3J11 draft.  The people
    who wrote those documents understand more of the motivations
    behind them.  I go by what I read. ]

    When C Standard Language-Dependent Support is provided, POSIX
    1003.1 defers to the ANSI C name-space-pollution rules.  When
    a feature test macro is #defined, it makes visible the set of
    symbols specified by that macro, in addition to the symbols
    specified by the C standard.  The usual case for portable
    POSIX applications is that the _POSIX_SOURCE feature test
    macro will be #defined, so the C standard symbols and the
    POSIX 1003.1 symbols will be visible.

    Under ANSI C, _LOW, _HIGH, __s, and __v are all reserved to the
    library implementor if they're external identifiers, because they
    all start with underscores.  In any standard header, they'll
    become externals when the header is #included with external scope.

    The question now becomes, is the header part of the library
    implementation or not?  If any compiler other than the native one
    will use these headers, the answer had best be `not'.

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

>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.

>4. Is the extra set of parenthesis around __v in _HIGH() really required?

    No.  `>>' has higher precedence than `&'.  Even so, when in doubt,
    parenthesize.  It makes the code easier for humans to read, and
    doesn't make it significantly more difficult for compilers
    to read.

>5. What is the best newsgroup for asking this sort of question?

    comp.std.unix; comp.std.c; comp.lang.c (point 4).

>Thanks.
>
>Andy Tanenbaum (ast@cs.vu.nl)

    You're welcome.

    If my interpretation is incorrect, someone please speak up.
    I want to understand this stuff.

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