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/
