apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Removing APR_STATUS_IS_SUCCESS macro
Date Fri, 10 May 2002 22:02:47 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> 
> 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. ]

++1 to everything in this message!

Ryan



Mime
View raw message