Some questions about POSIX headers

[Bob Lenk]

>#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)?

Yes.  They are in the namespace reserved for the implementation.

> 2. Are the parameters __s and __v required to begin with __ (again, name
>    space pollution rules)?

No.  The names of macro parameters do no impact the application's
namespace in any way.  They could be called printf and fork without
any problem.

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

I see no explicit restriction in POSIX (since these are described as
macros rather than functions).  At least in theory it's a bad idea.  In
practice, because WIFSIGNALED() is only meaningful if the argument is a
value returned via wait() or waitpid(), I see no reasonable way for its
argument to be an expression that would be harmful to evaluate twice.  I
could concoct some legal POSIX usage where the status is written to a
file and then an application does

	WIFSIGNALED(getc(stream))

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

Similar answer to (3).  In this case concoct something like

	WEXITSTATUS(status + 0)

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

This one seems reasonable to me.  Comp.std.unix would also be appropriate.

Of course these are my personal opinions only.  A binding interpretation
can only be issued by the IEEE (as described in the published standard).

		Bob Lenk
		rml at hpfcla.hp.com
		hplabs!hpfcla!rml