[vox-tech] errno upon success (a real success)?

[Michael Wenk]

Im not sure about glibc, but I had my Advanced Programming in the Unix
Environment out, and errno is never cleared after a successful function
call, and errno is never set to zero from any function call. and 0 should
not be pointed to by constants(ie, errno.h.)   The normal method of checking
errno is only when the return value of a function indicates an error has
occurred.  As for math functions, I don't use them very often myself, so Im
not aware of the exact behaviour.

Mike
----- Original Message -----
From: <msimons@moria.simons-clan.com>
To: <vox-tech@lists.lugod.org>
Sent: Wednesday, October 09, 2002 8:21 PM
Subject: Re: [vox-tech] errno upon success (a real success)?


> On Wed, Oct 09, 2002 at 03:15:46PM -0700, Peter Jay Salzman wrote:
> > i've read that system and library calls can set errno, even when they're
> > successful.
>
> Pete,
>
>   in the event of an error errno is defined to contain a description of
> what went wrong.  errno may be undefined after a library call returns
> success(*), don't check errno unless a function reports failure via it's
> return code and don't call other library calls before checking errno
> (or else you may clobber the real error).
>
> *:
>   I have thought that errno _was_ undefined after a successful call,
> but I can't point at anything that says so right now.
>
>   I've just skimmed around in glibc and I can see extensive work happening
> to save errno upon entering and to restore errno on exiting most of the
> libc functions.  so it looks like gnu libc tries to not have errno change
> unless a function fails.
>
>
> > does anyone know of an example where errno is set upon success that may
> > not be as much of a stretch as taking the square root of infinity?
>
>   I can't think of any functions that are documented to set errno and
> return successfully...
>   Even the way I read sqrt and atan docs, they don't modify errno
> on success.  thanks to their API using the function return value as
> the computed output value and the return values being non-ints (and
> equality comparison of floats is dangerous), they don't have an easy
> way to return "we have a problem"... as far as I can tell from the docs
> they modify errno only when there is an error.  if their API were like:
>   int sqrt(double input, double *output);
> were return 0 is success, then they wouldn't appear to
> "change errno on success", but they would be much more of a pain to use.
>
>
>   While the relevant section of glibc-doc doesn't go so far as to say
> errno is undefined after a successful call... it does suggest not checking
> unless an error code is returned and suggests a method of handling
> the math functions which can't return a proper error code (due to
> API).
>
> /usr/share/info/libc.info-2.gz
> #Checking for Errors
> #===================
> #
> #   Most library functions return a special value to indicate that they
> #have failed.  The special value is typically `-1', a null pointer, or a
> #constant such as `EOF' that is defined for that purpose.  But this
> #return value tells you only that an error has occurred.  To find out
> #what kind of error it was, you need to look at the error code stored in
> #the variable `errno'.
> [...]
> #     The initial value of `errno' at program startup is zero.  Many
> #     library functions are guaranteed to set it to certain nonzero
> #     values when they encounter certain kinds of errors.  These error
> #     conditions are listed for each function.  These functions do not
> #     change `errno' when they succeed; thus, the value of `errno' after
> #     a successful call is not necessarily zero, and you should not use
> #     `errno' to determine _whether_ a call failed.  The proper way to
> #     do that is documented for each function.  _If_ the call failed,
> #     you can examine `errno'.
> #
> #     Many library functions can set `errno' to a nonzero value as a
> #     result of calling other library functions which might fail.  You
> #     should assume that any library function might alter `errno' when
> #     the function returns an error.
> [...]
> #     There are a few library functions, like `sqrt' and `atan', that
> #     return a perfectly legitimate value in case of an error, but also
> #     set `errno'.  For these functions, if you want to check to see
> #     whether an error occurred, the recommended method is to set `errno'
> #     to zero before calling the function, and then check its value
> #     afterward.
>
>     TTFN,
>       Mike
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>