>> If I am writing a function that sets errno according to a possible
error condition, should it also set errno to 0 if it executes
normally, or should it leave errno alone on success?
Your choice, really. No Standard library function ever sets
`errno' to zero (7.5/3), so if you want to follow their precedent
you won't do so either.
Note, also, that most library functions do not use `errno' as
a failure indicator, but to convey additional information about a
failure reported by other means. A library function may change
the value of `errno' even if it succeeds (same reference).
Finally, I would discourage you from using `errno' this way.
There are only three Standard-required Exxxx macros, so if you
try to use others you run into portability problems. And there's
no mechanism for extending the implementation' s `errno' codes with
your own: Quite aside from the problem of finding a value that hasn't
already been given some other meaning, there's the issue of making
your new codes known to strerror() and perror(). Even for the codes
defined by the Standard and the implementation, `errno' is a pretty
puny interface: limited bandwidth on fragile underpinnings. You
can almost certainly do better.
Consider using the com_err library. It is present in a number of
BSD Unix distributions, and although it seems to make a few unportable
assumptions (like the C-implementation-defined values of errno are
"small", as in having values limited to between 1 and 255, inclusive),
it's reasonably portable.
com_err allows independent parts of a program to register their own
set of error codes (one "set" of error codes is 256 of them; but
nothing prevents one module from registering and using more than
one "set" if it needs them. There are something like 2^24 "sets"),
and for the caller of a function to turn that error code into text
even if it does not know about the error code or even what sub-part
of the program it came from. C-implementation-defined error codes
used with errno, perror(), and strerror() are also pre-registered.
If the C-implementation-defined error codes are not within the
assumed range, and you know what that range is, it isn't difficult
to arrange to pre-register them with a code change to com_err
specific to your implementation. Or, maybe you don't even care
about pre-registering the C-implementation-defined error codes.
The com_err library does *NOT* standardize the use of errno. Most
of the functions I've seen using it return the error code or 0 for
success, (which is thread-safe, reentrant, avoids issues of leftover
previous errors that make no sense in the current context, and is
generally better style), rather than using a global variable. But
if you want to use it with errno or return it in some other global,
it works. It's up to you to figure out where the error code is
(errno, h_errno, return from a function, etc.) and feed it to
com_err(), the analog of perror(), or error_message() , the analog
of strerror().
com_err comes with a compiler that turns a file full of error message
symbols and text into C code which you then compile and put in your
program.
Gordon L. Burditt
