Email List: Xaustin-review-lX
[All Lists]

Re: Defect in XBD unistd.h

To: Geoff Clare <yyy@xxxxxxxxxxxxx>
Subject: Re: Defect in XBD unistd.h
From: Mark Brown <yyyyy@xxxxxxxxxx>
Date: Mon, 26 Apr 2004 10:20:26 -0500
Cc: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
Geoff Clare wrote:
> The descriptions on the <unistd.h> page under the heading "Constants
> for Options and Option Groups" of the "undefined" case and the "defined
> with value zero" case are separate and slightly different.  This can
> mislead some readers into thinking that there must be some subtle
> difference between the two cases, when in fact the intention was for
> the requirements to be exactly the same.  (This intention is clear
> from the explanation of the new options mechanism in the rationale on
> the <unistd.h> page.)

The difference was intentional, or else we would have made the presence of
all the associated header files mandatory instead of optional for 
starters.

This was brought in in austin-review-l #831 by Jon Hitchcock:
> @ page 413 line 14289-301 section unistd.h comment {jjh20}
> 
> Problem:
> 
> It is not clear how a portable application can allow for the case
> where a constant is undefined.  The existence of headers, etc,
> is guaranteed if it has the value zero, but not if it is undefined.
> Why is there a need for 4 cases (-1, 0, +ve, undefined)?  It would
> not be difficult for an implementation to define all the macros.
> 
> Action:
> 
> Change lines 14289-91 to say:
> 
> The following symbolic constants shall be defined in <unistd.h>,
> and shall have a value of -1, 0, or greater, unless otherwise
> specified below.
> 
> OR
> 
> Change to use the three cases (-1, undefined, +ve).  This is more
> compatible with existing applications that take a definition not
> equal to -1 to mean "always supported".
> 
> OR
> 
> Provide an example in Application Usage to show how to test one of
> these constants and how to conditionally include a header.

This went into the March 2001 Aardvark resolution meeting as ERN376.
ERN367 was marked "reject" with the following comment:
> "This methodology was introduced in 1003.1a after much debate. 
> We believe the rationale on page 430 explains this sufficiently."


-------------------
Mark S. Brown 
STSM, UNIX/Linux OS Standards
IBM Systems Group, Linux Technology Center
yyyyy@xxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>