sscanf always generates error condition

[Geraldo Veiga]

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

In article <1991May1.024357.7750 at dg-rtp.dg.com> hunt at 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.