On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote:
> At 06:39 PM 10/13/2002, [EMAIL PROTECTED] wrote:
> >On Sun, 13 Oct 2002, Aaron Bannert wrote:
> >
> >> On Sun, Oct 13, 2002 at 11:53:27AM -0400, Ryan Bloom wrote:
> >> > > Is there a more APR-ish way to describe returning "true" or "false"
> >> > > than
> >> >
> >> > As with all other APR functions. APR_SUCCESS indicates "true", Some
> >> > other
> >> > APR_STATUS code indicates false.
> >>
> >> No it doesn't. True and false can be orthogonal to success/failure.
> >> How does one express a successfully false condition?
> >
> >that is why it is apr_status_t, not apr_error_t. There are specifically a
> >set of status codes that do not indicate errors, only status
> >conditions. That series of values starts with APR_OS_START_STATUS, and
> >examples of them are APR_INCHILD, APR_INPARENT, APR_DETACH. They are
> >commonly identified by the fact that they aren't APR_E*, rather they are
> >just APR_*.
>
> Shouldn't these consistently return true for APR_STATUS_IS_SUCCESS()?
> Seems like a good argument for retaining that macro we debated before.
No, they shouldn't. If those macros tested true for success, then it
would lead to a great deal of developer confusion. For the most part, the
functions that return status codes either can't return APR_SUCCESS or they
return APR_SUCCESS to mean true. If you make these macros test true, then
you will end up with potentially meaningless code like:
rv = apr_proc_wait(proc, &exit, &why, APR_WAIT)
if (APR_STATUS_IS_SUCCESS(rv)) {
/* No clue if the process is dead or not, because the test is
* meaningless. */
}
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
