Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.7 $; site uiucuxc
Path: utzoo!linus!philabs!cmcl2!seismo!harpo!whuxlm!whuxl!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.Uiuc.ARPA
Newsgroups: net.bugs.4bsd
Subject: Re: Bug in isatty (all systems!)
Message-ID: <2200011@uiucuxc>
Date: Sat, 27-Jul-85 20:25:00 EDT
Article-I.D.: uiucuxc.2200011
Posted: Sat Jul 27 20:25:00 1985
Date-Received: Tue, 30-Jul-85 05:46:58 EDT
References: <965@sdcsvax.UUCP>
Lines: 32
Nf-ID: #R:sdcsvax.UUCP:-96500:uiucuxc:2200011:000:1668
Nf-From: uiucuxc.Uiuc.ARPA!hamilton    Jul 27 19:25:00 1985


>  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?

    RTFM is STILL applicable here...
    "not cleared on successful calls" means exactly what it says:
"successful calls to the functions IN SECTION 2 do not clear errno".
    notice that that quote is from intro(2), while the functions
causing all this ruckus are from section 3, and intro(3) mentions
errno only in the context of math functions.  i don't want to dig
out my V6 manuals, but i'm fairly sure errno used to be exclusively
maintained by the system call interface functions.  library functions
are NOT system calls.  they are "customers" of section 2 and errno just
as your code is.  whether they should be messing with the system call
interface is debatable; do all of YOUR subroutines clear errno upon
successful return?
	wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton