apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Reducing #ifdef burden on APR applications
Date Mon, 22 Aug 2005 12:35:48 GMT
On Monday 22 August 2005 13:12, Joe Orton wrote:


> > Erm, because ENOTIMPL is an error, whereas this noop isn't?
>
> Now I'm confused; all apr_status_t values other than 0 are "errors" by
> definition.  If you mean, "because the caller can be taught to treat
> APR_NOOP as non-fatal", well, sure; the caller can equally be taught to
> treat APR_ENOTIMPL as non-fatal.

I disagree.  For example, APR_EOF is an end-condition, not an error.
apr_errno even defines different ranges of codes for different things.

In practical terms, suppose I implement APR for Platform X, but leave
some parts (which my application doesn't happen to need)
unimplemented, returning APR_ENOTIMPL.  Now if we've used APR_ENOTIMPL
for a no-op success, *all apps* that use the feature have lost the distinction
between success and a failure that can't be ignored.

-- 
Nick Kew

Mime
View raw message