Setting errno

[Paul Emmons]

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?

 

[Dan Pop]

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?

Leave it alone on success. If the function reports successful completion,
the programmer has no business at all to look at errno.

Strictly speaking, you can do anything you want with errno in case of
success, but it's common practice to preserve its value in case of
success.

Dan

 

[Eric Sosman]

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.

 

[Gordon Burditt]

If I am writing a function that sets errno according to a possible

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

 

[Paul Emmons]

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.

Thank you! I'm aware that it is not one of the more admired features
of the language, and I very often do have my functions return their
own error codes according to a set of my own (0 for success, or a
negative value indicating a particular kind of error). I wouldn't
try to invent my own codes for errno, and use them only for a few
functions that are similar to library functions setting ERRNO, and
when one of the standard codes is appropriate, such as
ERANGE or EINVAL.