elm 2.5.3 and glibc 2.1.93

[Mark Kettenis]

   Date: Fri, 22 Sep 2000 15:29:10 -0500
   From: Mark Brown <bmark@us.ibm.com>

   "H . J . Lu" wrote:
   > The initial value of @code{errno} at program startup is zero.  Many
   > library functions are guaranteed to set it to certain nonzero values
   > when they encounter certain kinds of errors.  These error conditions are
   > listed for each function.  These functions do not change @code{errno}
   > when they succeed;
   > ---
   > 
   > I have quoted it in my previous email. Did I read it wrong?

   Nope, I apologize -- but that last sentence is both bad and wrong, IMHO.

There is some confusion between ISO C and POSIX here.  The copy of the
ISC C 9X draft I have here says (7.5 Errors <errno.h>):

 [#3]  The  value of errno is zero at program startup, but is
       never set to zero by any library function.159)  The value of
       errno  may  be  set  to  nonzero  by a library function call
       whether or not there is an error, provided the use of  errno
       is not documented in the description of the function in this
       International Standard.

Which implies that if errno is documented for an ISO C function, it
may not be set to non-zero by a successfull call of function.  That's
probably what led to the bit of text in the glibc documentation that
HJ quoted.

The Austin draft clearly states that (2.3 Error Numbers):

  The value of errno should only be examined when it is indicated to
  be valid by a function's return value.

I assume that this is equivalent to what the current POSIX standard
says.

Since fcntl is not an ISO C function, its current behaviour is
perfectly fine, and elm isn't a POSIX conforming application and
should be fixed.

Somebody, preferably a native speaker, should probably clarify the
glibc manual on this issue.

Mark