perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: additional APR::Status::is_* functions?
Date Sat, 07 May 2005 23:58:53 GMT
On Sat, 7 May 2005, Stas Bekman wrote:

> Randy Kobes wrote:
> > In the t/protocol/ tests, there's some comparisions of $@ to
> > APR::Const::ECONNABORTED and APR::Const::EOF made. As such,
> > it may be an idea to add and use
> > APR::Status::is_ECONNABORTED and APR::Status::is_EOF
> > instead. At the present time APR_EOF doesn't have any
> > variants:
> >   #define APR_STATUS_IS_EOF(s) ((s) == APR_EOF)
> > But for consistency with the other uses of APR::Status,
> > would it be an idea to add this anyway?
> > This would
> > also handle possible changes to APR_STATUS_IS_EOF(s)
> > in the future.
> +1 for ECONNABORTED, as it's already a composite
> not sure about EOF (not a composite at the moment), may be
> ask at apr-dev?
> > In the same vein, there are variants in the
> > APR_STATUS_IS_SUCCESS(s) macro. This hasn't been a
> > problem yet, but should we add an APR::Status::is_SUCCESS
> > to be used in place of comparison to APR::SUCCESS?
> Hmm, the API starts to get confusing with having two ways.
> Again I'd ask @apr-dev if this is essential, but it looks
> like we need to do it, as it's again a composite.

Actually, in browsing the apr-dev mail archives, there was a
discussion of the APR_STATUS_IS_SUCCESS() macro,
particularly about dumping it. It's now gone in the current
apr svn trunk. So I guess we should leave things as
they are, and just compare with APR::SUCCESS?

However, most of the other APR_STATUS_IS_* macros have this
warning in apr_errno.h:
   * always use this test, as platform-specific variances
   * may meet this more than one error code
as well as comments after the definition of the error
code like
   * @warning use APR_STATUS_IS_ECONNABORTED instead of just
   * testing this value
even for those for which there's no composite, at present.
As you say, it is confusing having two ways of accessing
these, but perhaps we should follow apr's guide in this
respect, and provide APR::Status::is_* for those macros
which contain this recommendation for use (for the
APR::Const::* provided)?

> Also while fixing docs, please locate the standalone constants in the
> APR::Const manpage and add a link to the corresponding APR::Status macros
> (and a reversed link to), see the APR::Const::EAGAIN and
> APR::Status::is_EAGAIN pod entries for an example.

I'll do that - thanks.

best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message