Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!stanford.edu!agate!violet.berkeley.edu!ilan343
From: ilan343@violet.berkeley.edu (Geraldo Veiga)
Newsgroups: comp.unix.programmer
Subject: Re: sscanf always generates error condition
Message-ID: <1991May1.193252.16232@agate.berkeley.edu>
Date: 1 May 91 19:32:52 GMT
Article-I.D.: agate.1991May1.193252.16232
References: <1991Apr30.233554.1321@agate.berkeley.edu> <1991May1.024357.7750@dg-rtp.dg.com>
Sender: root@agate.berkeley.edu (Charlie Root)
Distribution: usa
Organization: University of California, Berkeley
Lines: 41

First of all, thank you for all postings and mail helping me  with 
this question.

In article <1991May1.024357.7750@dg-rtp.dg.com> hunt@dg-rtp.rtp.dg.com writes:
>Errno is not set on successful conclusion of calls, only on ones that
>encountered an error.

Ok. 

>Since your example discards the return value from sscanf, you can't
>test it to see if some error occurred before you look at errno.  In
>the test case, errno is being used without having a value assigned to
>it, so the "9" is just garbage that happened to be in the memory
>associated with errno at the time.  On the other system you tried, the
>garbage happened to have been zero, so everything worked.

This was not the case.   In the ISC system call errno=0 (or whatever I
set it to) before and errno=9 after.  Also, sscanf returns 1 
(as it should in my example).

>Take a closer look at the man page for sscanf, particularly the parts
>describing the return value.  You'll need to change your code to
>capture the return value in a variable, and then test it to see if
>an error occurred.  If so, then call perror.  Don't call it otherwise.

This problem came up because I have a generic error message function
used for both system and user errors.  This function always checks the
value of errno and prints whatever system error message was indicated 
(with a perror() call).

From the discussion in this and one previous posting, this doesn't seem
a like very good idea, since a system call could set the value of errno
to some misleading value that would generate a non-related message
next time I print a user error message.

>This is a pretty common mistake to make, so don't feel bad about it.
>It's not intuitive, is it?  You'd think that errno would be set to
>zero if the call works, but that's not done for performance reasons.

I was aware that the it wouldn't set errno=0, but setting it to a
non-zero value on normal termination still bothers me.