Path: utzoo!utdoe!contact!robohack!eci386!ecicrl!clewis
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.unix.programmer
Subject: Re: sscanf always generates error condition
Message-ID: <1474@ecicrl.ocunix.on.ca>
Date: 7 May 91 13:41:10 GMT
References: <1991Apr30.233554.1321@agate.berkeley.edu> <1991May1.024357.7750@dg-rtp.dg.com> <1991May7.020259.3646@athena.mit.edu>
Distribution: usa
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 34

In article <1991May7.020259.3646@athena.mit.edu> scs@adam.mit.edu writes:

>As has been (correctly) pointed out, however, it's not incorrect
>for ISC's sscanf to be leaving EBADF in errno, because (to quote
>from an old version of the comp.lang.c frequently-asked questions
>list), "it is only meaningful for a program to inspect the
>contents of errno after an error has occurred (that is, after a
>library function that sets errno on error has returned an error
 ^^^^^^^^^^^^^^^^
>code)."

The underlined phrase should be "system call".  Library routines
can return an error yet the errno won't indicate the real reason
for the failure.  Most modern versions of the manual pages document
exactly which system calls set the errno, and describe the causes
for each one.  Ie: "errno is only relevant when a system call that
is documented to set errno indicates an error has occured by its
return value".

(The more common guise under which this issue comes up
>is "Why does errno contain ENOTTY after a call to printf?")

>                                            Steve Summit
>                                            scs@adam.mit.edu

Put the way this usually crops up: "Why did your sendmail bounce
my mail with a:
	550 ... Not a tty
message" ;-)
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!