elm 2.5.3 and glibc 2.1.93

[Mark Kettenis]

   Date: Sat, 23 Sep 2000 08:45:19 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Sat, Sep 23, 2000 at 03:19:33PM +0200, Mark Kettenis wrote:
   > 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.
   > 

   See the code segment in

   http://sources.redhat.com/ml/libc-hacker/2000-09/msg00148.html

That code is broken.  It probably works on most Unixes if bar is a
system call, but if it isn't, it is likely to fail on quite a few of them.

   It doesn't violate any standard if glibc doesn't change errno for
   successful return as stated in the glibc manual. For the better
   or worse, we just cannot change the documented glibc behavior unless
   we have a really good reason. Otherwise, we can just delete the whole
   glibc manual since it doesn't mean anything and the glibc behavior can
   change at any time.

Changing errno can be a rather expensive operation.  

   Please think what it meanes to the Linux application developers. At
   least, we will lose any credibility we have in the glibc manual. We
   cannot even tell them "read and follow the glibc manual." What does
   it tell the world?

My copy of the manual says that:

     ... you should not use `errno' to determine _whether_ a call
     failed.  The proper way to do that is documented for each
     function.  _If_ the call the failed, you can examine `errno'.

So people who have been reading the manual should not have written
incorrect code.  It is true that the language in the manual is
contradictory.  That is a bug in the manual and should be fixed in the
manual.  Not by penalizing correctly written code.

Mark