apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Removing APR_STATUS_IS_SUCCESS macro
Date Fri, 10 May 2002 21:55:44 GMT
On Fri, May 10, 2002 at 05:13:44PM -0400, Cliff Woolley wrote:
> On Fri, 10 May 2002, Aaron Bannert wrote:
> 
> > > if (my_apr_err) {
> > >   ..uh-oh...
> > > }
> >
> > this one bad.
> >
> >
> > > if (my_apr_err != APR_SUCCESS) {
> > >   ..uh-oh...
> > > }
> >
> > this one good. :)

Stylistic nits, but both are *WAY* better than the macro.

>...
> Do we really need the ERROR_SUCCESS and NO_ERROR thingies?  Do they ever

If a function returns non-zero for *success*, then the function is buggy.

When apr_status_t was first designed, the one and ONLY requirement for it
was that "success == 0". By DEFINITION, an apr_status_t will and must be
zero if success occurred.

Thus, the macro is bogus, and the platform specific NO_ERROR and whatnot is
totally bogus (because the relevant functions should NEVER return that).

Bill Rowe pointed out that EINCOMPLETE is "success". However, it isn't
really "success" in the same sense. It is returning status information,
which an application can use to direct its flow, but it is not the
unequivocal "success" defined by APR_SUCCESS and the value 0. I'm not sure
that it enters the discussion here at all.

[ functions that perform work successfully, yet need to return something to
  indicate "hey, I'm not done" or "you need to give me more data" or
  whatever should have those alternative "error" values well-documented in
  the header file. apps will test against those values to determine what
  further action needs to happen. ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message