Bug in isatty (all systems!)

[Alexis Dimitriadis]

> >  ... I designed a large software system around
> > the assumption that errno was always valid and not set as a side-effect.
> > It took me 6 months (admittedly, I wasn't looking hard) to figure out
> > why I was always getting "not a typewriter" (because my open routine 
> > was setting a struct bit to indicate tty/non-tty for every file).
> 
> My 4.2bsd manual describes this in the INTRO(2) section, right before the
> list of errno values.  Just where would you prefer that it be mentioned?
> RTFM!

  MY 4.2bsd manual says:

      ... An
     error number is also made available in the external variable
     _errno_, which is not cleared on successful calls.  Thus _errno_
     should be tested only after an error has occurred.

  What does "not cleared on successful calls" mean to you?  To me, it
means that if I set errno = 0 in the beginning of my program, it will
stay zero until a system call _fails_, then it will stay non-zero long
enough for me to do something about it.  Now if a perfectly successful
operation sets errno and does not bother to clear it, how can I depend
on errno as an indication that something went _wrong_?

  Remember, TFM does not say anywhere that _successful_ operations set
errno, which is what, in effect, happens here.  Or should the whole
world know how fopen() is implemented, in order to decipher errno
in context?

  If I did not dream of this, one of the proposed standards has a passage 
to the effect that "function calls may set errno to arbitrary values, 
as long as their effect on errno is _not_ documented".  In other words, 
don't check errno after calling a library routine unless the manual says
that it sets errno to something meaningful.  Sigh.

Alexis Dimitriadis
-- 
_______________________________________________
  As soon as I get a full time job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.

             alexis @ reed

	         ...teneron! \
...seismo!ihnp4! - tektronix! - reed.UUCP
     ...decvax! /