Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cmcl2!hsdndev!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: sscanf always generates error condition
Message-ID: <1991May3.095541.21439@athena.mit.edu>
Date: 3 May 91 09:55:41 GMT
References: <1991Apr30.233554.1321@agate.berkeley.edu> <1991May1.024357.7750@dg-rtp.dg.com> <1991May1.193252.16232@agate.berkeley.edu> <1991May2.134354.9719@dg-rtp.dg.com>
Sender: news@athena.mit.edu (News system)
Distribution: usa
Organization: Massachusetts Institute of Technology
Lines: 27

In article <1991May2.134354.9719@dg-rtp.dg.com>, hunt@dg-rtp.rtp.dg.com (Greg Hunt) writes:
|> GV> I was aware that the it wouldn't set errno=0, but setting it to a
|> GV> non-zero value on normal termination still bothers me.
|> 
|> It would bother me, too.  It might be a bug in the ISC sscanf library
|> call (albeit a fairly harmless one since the function works and does
|> return the proper value).

  It is *not* a bug.  The specification of the system call interface is that
if a system call succeeds, errno is irrelevant, and its value is undefined. 
The value is only defined if the system call fails.

  There are quite a few system calls in the kernel that set errno to a value,
then try the operation which would cause that error value if it failed, and
then return immediately it it fails, signalling an error.  They're allowed to
do that.

  You cannot count on the value of errno being zero if a function succeeds. 
That's the way the system call interface is designed, and, in all likelihood,
that design is ingrained in too many different systems for it to be changed in
the foreseeable future.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710