Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!ittatc!dcdwest!sdcsvax!jww
From: jww@sdcsvax.UUCP (Joel West)
Newsgroups: net.bugs.4bsd,net.unix-wizards,net.bugs.usg
Subject: Re: Bug in isatty (all systems!)
Message-ID: <1023@sdcsvax.UUCP>
Date: Fri, 2-Aug-85 19:30:48 EDT
Article-I.D.: sdcsvax.1023
Posted: Fri Aug  2 19:30:48 1985
Date-Received: Sun, 4-Aug-85 07:02:54 EDT
References: <6367@ucla-cs.ARPA> <997@sdcsvax.UUCP> <1017@ulysses.UUCP> <1730@reed.UUCP> <1298@eagle.UUCP>
Organization: CACI, Inc - Federal, La Jolla
Lines: 49
Xref: linus net.bugs.4bsd:1354 net.unix-wizards:11364 net.bugs.usg:264

(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@SDCSVAX.ARPA