Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3195

Re: Return value for error

Show all headers | View raw

Stephen Sprunk <stephen@sprunk.org> wrote:
> On 03-May-11 03:31, pozz wrote:
> > A very simple question. What do you use as the return value of a
> > function for error/ok results?
> > I can't decide between 0 for error and !=0 for ok, or 0 for ok and !=0
> > for errors.

> General rules:

> 1. If one success state and many error states, let 0 indicate success.

> 2. If one error state and many success states, let 0 indicate error.

> 3. If many success states and many error states, let negative indicate
> error and non-negative indicate success.

This is the approach taken by snprintf(), and it's very annoying. On success
you end up with a value that really should be kept in a size_t, for
comparing with other similar values. Which means you inevitably end up
having to convert (or worry about missed implicit conversions) the value in
the common case. Then, to make matters worse, almost half the value space is
wasted for a simple -1. And to add insult to injury, although there can be
multiple error states, you still have to query a separate object. (So I
guess it sort of falls between #2 and #3.)

I would discard #3. If there are many error states, overload a single value
in the success space (an unlikely value, like 0, or more importantly a value
which if misused is unlikely to cause havoc, also typically 0), and take a
separate parameter analogous to errno. Otherwise, just return an errno-like
object.

I religiously follow #1 and #2. If #1, I return an (int). If #2 I take a
pointer to an (int). Positive values for the (int) object are reserved for
saving errno or reusing standard error macros. The standard says that errno
values most be positive, and if POSIX doesn't also guarantee this for
extensions it appears to be the universal behavior.

Negative values I reserve for application use, to be apportioned to each
library. To avoid clashes, present and future, I store in the upper bits a
likely unique identifer. For example, the error range for my DNS library
will start at -(('D' << 24) | ('N' << 16) | ('S' << 8)). (I realize (int) is
only guaranteed to be 16-bits, but the principle still applies, although
perhaps not as simple.)

I've toyed with the idea of overloading strerror(), but in general as long
as library dependencies are hierarchical and fairly shallow (as they almost
always are in practice), then simply passing an error value to the
_strerror() method of a library is sufficient, and each library can forward
negative errors as necessary, passing positive errors to strerror().

I use this method everywhere, often wrapping standard routines like malloc
and snprintf:

	void *make(size_t size, int *error);
	size_t fmtstr(void *dst, size_t lim, int *error, const char *fmt, ...);

It has worked extremely satisfactorily for a couple of years now. Since I
settled on this solution I haven't looked back. It has regularized by my
error handling habits, where how a particular routine returns an error is
not nearly as important as consistency and convenience across all the
routines.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Return value for error pozz <pozzugno@gmail.com> - 2011-05-03 01:31 -0700
  Re: Return value for error jacob navia <jacob@spamsink.net> - 2011-05-03 10:46 +0200
  Re: Return value for error Ike Naar <ike@otaku.freeshell.org> - 2011-05-03 09:04 +0000
    Re: Return value for error Ian Collins <ian-news@hotmail.com> - 2011-05-03 21:19 +1200
  Re: Return value for error James Kuyper <jameskuyper@verizon.net> - 2011-05-03 06:26 -0400
    Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:03 -0700
      Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-04 05:15 -0700
        Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-04 08:26 -0700
          Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-04 17:08 -0700
            Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-04 17:54 -0700
              Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:03 -0700
  Re: Return value for error James Dow Allen <jdallen2000@yahoo.com> - 2011-05-03 03:45 -0700
    Re: Return value for error Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-03 20:50 +0000
  Re: Return value for error pete <pfiland@mindspring.com> - 2011-05-03 07:50 -0400
    Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:04 -0700
  Re: Return value for error Martin Ambuhl <mambuhl@earthlink.net> - 2011-05-03 07:59 -0400
  Re: Return value for error Mark Storkamp <mstorkamp@yahoo.com> - 2011-05-03 08:46 -0500
  Re: Return value for error Stephen Sprunk <stephen@sprunk.org> - 2011-05-03 10:13 -0500
    Re: Return value for error William Ahern <william@wilbur.25thandClement.com> - 2011-05-03 13:08 -0700
  Re: Return value for error Kenneth Brody <kenbrody@spamcop.net> - 2011-05-03 13:23 -0400
    Re: Return value for error Peter Nilsson <airia@acay.com.au> - 2011-05-03 16:01 -0700
    Re: Return value for error Nobody <nobody@nowhere.com> - 2011-05-05 07:21 +0100
      Re: Return value for error Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 15:13 +0100
        Re: Return value for error Nobody <nobody@nowhere.com> - 2011-05-06 03:51 +0100
          Re: Return value for error James Kuyper <jameskuyper@verizon.net> - 2011-05-05 23:38 -0400
      Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-05 08:44 -0700
        Re: Return value for error Seebs <usenet-nospam@seebs.net> - 2011-05-05 20:49 +0000
          Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-05 14:10 -0700
            Re: Return value for error Seebs <usenet-nospam@seebs.net> - 2011-05-06 00:26 +0000
  Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:09 -0700

csiph-web