Bug in isatty (all systems!)

[Joel West]

(This is becoming  a tedious quasi-religious issue, but since it was 
my original point, I'd like to respond to some of the criticisms to it...)

> > > >  ... I designed a large software system around
> > > > the assumption that errno was always valid and not set as a side-effect.
> > > 
> 
> All of the routines in section 2 (system calls) have a return value which
> indicates that errno contains the reason why it failed.  There are also some
> routines in section 3 which behave the same way.  They are all adequately
> documented.  

No where does the documentation explicitly say "Some routines which return
successful results may, as a side-effect, set the value of errno to an
arbitrary value."  In addition, I would consider such cases to warrant
mention in the "Special Considerations" :-) section.

> The suggestion to "RTFM" is absolutely correct.  You cannot depend
> on errno to tell you that an error occurred; it only tells you what the *last*
> error from one of those routines which sets errno (on detection of an error)
> was.  

You are correct, the software does behave this way.  The design, however,
is counter-intuitive on this point.  To be specific, some implementation
shortcuts compromised a clean design that would have been worked with BOTH
of our respective interpretations.

> A perfectly successful operation will not return an failure value, thus
> errno should not be consulted to see what the non-error was.

> >   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.
> 
> No, that sentence should read:
> 	In other words, don't check errno after calling a library routine
> 	unless it returns an error indication *and* the manual says that it
> 	sets errno to something meaningful.

If you're a defender of the cult of UNIX and its teachings, the latter
is a reasonable statement.  If you want clear and unambiguous documentation
(which fits my definition of a printed "standard") the former is better.


	Joel West	CACI, Inc. - Federal (c/o UC San Diego)
	{ucbvax,decvax,ihnp4}!sdcsvax!jww
	jww at SDCSVAX.ARPA