You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2005/05/09 00:51:48 UTC
advice on use of APR_STATUS_IS_*
mod_perl 2 supplies some APR::* modules for binding to apr,
and a question has arisen regarding checking error codes
against the appropriate APR_* constants. In apr_errno.h
there are warnings about using the corresponding
APR_STATUS_IS_* macros, as there could be more than one
variant satisfying an error condition (eg,
APR_STATUS_IS_ENOENT). There are a number of cases though
for which at present there's only one such condition (eg,
APR_STATUS_IS_EOF). What we were wondering is if the
APR_STATUS_IS_* macros are still strongly recommended to use
in cases where there is only one variant? Or, for such
cases, has common useage become just to compare against the
corresponding APR_* constant (eg, APR_EOF)? Thanks very
much.
--
best regards,
randy kobes
Re: advice on use of APR_STATUS_IS_*
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:20 PM 5/11/2005, Wesley W. Garland wrote:
>If I had my fantasy implementation, though, codes like EAGAIN and
>EWOULDBLOCK would be merged into one result... but that would
>require... well, all factors considered, a time travel machine and way
>to encourage cooperation between the USL and BSD guys prior to 4.3
>Reno or so.
Exactly. Where some libraries have some normalize_err() function
which folds these together, the cost of executing *that* switch,
then to go through the users' expected cases, is much much to high
for performant apps.
The advantage of STATUS_IS macros is that only those flags your
app is prepared to handle are evaluated.
Bill
Re: advice on use of APR_STATUS_IS_*
Posted by "Wesley W. Garland" <we...@gmail.com>.
Good Point, Will -- definately an argument *for* using the
APR_STATUS_IS* macros.
I generally forget those exceptions (and that example is a very common
one) due to my habit of solving that issue with a switch(), combined
with the fact that I'm very UNIX-centric. (I don't use APR because
it's portable -- I use it because it's good and I like pools).
If I had my fantasy implementation, though, codes like EAGAIN and
EWOULDBLOCK would be merged into one result... but that would
require... well, all factors considered, a time travel machine and way
to encourage cooperation between the USL and BSD guys prior to 4.3
Reno or so.
Wes
On 5/11/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> IIUC, if you look, there are groups of status results under
> a single case. This is especially true on OS/X and Win32.
>
> But even on unix; consider
>
> /** operation would block */
> #if !defined(EWOULDBLOCK) || !defined(EAGAIN)
> #define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN)
> #elif (EWOULDBLOCK == EAGAIN)
> #define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN)
> #else
> #define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN \
> || (s) == EWOULDBLOCK)
> #endif
>
> which deals with this fundemental discrepancy between implementations.
>
> At 08:38 PM 5/11/2005, Wesley W. Garland wrote:
> >Aside from stylistic consistency, I can't see a compelling reason for
> >using the APR_STATUS_IS_* macro group -- and I think a viable case
> >could be made for avoiding them entirely for a fresh codebase. (For
> >example, I have 49,773 lines of apr-centric application code here...
> >and zero lines where APR_STATUS_IS_* appears).
> >
> >If I was working on PERL APR:: bindings, I would choose whatever is
> >the best expression for the language. Not knowing PERL, I can't really
> >comment there.
> >
> >For what it's worth, I feel fairly strong about using two types of return calls:
> >
> >1. check against != APR_SUCCESS
> >2. check using switch() with a default: case
> >
> >...and I really hate unnecessary macros.
> >
> >But this is more of a religious discussion than an APR discussion, so
> >I won't expound further. :)
> >
> >Wes
> >
> >On 5/8/05, Randy Kobes <ra...@theoryx5.uwinnipeg.ca> wrote:
> >> mod_perl 2 supplies some APR::* modules for binding to apr,
> >> and a question has arisen regarding checking error codes
> >> against the appropriate APR_* constants. In apr_errno.h
> >> there are warnings about using the corresponding
> >> APR_STATUS_IS_* macros, as there could be more than one
> >> variant satisfying an error condition (eg,
> >> APR_STATUS_IS_ENOENT). There are a number of cases though
> >> for which at present there's only one such condition (eg,
> >> APR_STATUS_IS_EOF). What we were wondering is if the
> >> APR_STATUS_IS_* macros are still strongly recommended to use
> >> in cases where there is only one variant? Or, for such
> >> cases, has common useage become just to compare against the
> >> corresponding APR_* constant (eg, APR_EOF)? Thanks very
> >> much.
> >>
> >> --
> >> best regards,
> >> randy kobes
> >>
> >
> >
> >--
> >Wesley W. Garland
> >Director, Product Development
> >PageMail, Inc.
> >+1 613 542 2787 x 102
>
>
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Re: advice on use of APR_STATUS_IS_*
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
IIUC, if you look, there are groups of status results under
a single case. This is especially true on OS/X and Win32.
But even on unix; consider
/** operation would block */
#if !defined(EWOULDBLOCK) || !defined(EAGAIN)
#define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN)
#elif (EWOULDBLOCK == EAGAIN)
#define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN)
#else
#define APR_STATUS_IS_EAGAIN(s) ((s) == APR_EAGAIN \
|| (s) == EWOULDBLOCK)
#endif
which deals with this fundemental discrepancy between implementations.
At 08:38 PM 5/11/2005, Wesley W. Garland wrote:
>Aside from stylistic consistency, I can't see a compelling reason for
>using the APR_STATUS_IS_* macro group -- and I think a viable case
>could be made for avoiding them entirely for a fresh codebase. (For
>example, I have 49,773 lines of apr-centric application code here...
>and zero lines where APR_STATUS_IS_* appears).
>
>If I was working on PERL APR:: bindings, I would choose whatever is
>the best expression for the language. Not knowing PERL, I can't really
>comment there.
>
>For what it's worth, I feel fairly strong about using two types of return calls:
>
>1. check against != APR_SUCCESS
>2. check using switch() with a default: case
>
>...and I really hate unnecessary macros.
>
>But this is more of a religious discussion than an APR discussion, so
>I won't expound further. :)
>
>Wes
>
>On 5/8/05, Randy Kobes <ra...@theoryx5.uwinnipeg.ca> wrote:
>> mod_perl 2 supplies some APR::* modules for binding to apr,
>> and a question has arisen regarding checking error codes
>> against the appropriate APR_* constants. In apr_errno.h
>> there are warnings about using the corresponding
>> APR_STATUS_IS_* macros, as there could be more than one
>> variant satisfying an error condition (eg,
>> APR_STATUS_IS_ENOENT). There are a number of cases though
>> for which at present there's only one such condition (eg,
>> APR_STATUS_IS_EOF). What we were wondering is if the
>> APR_STATUS_IS_* macros are still strongly recommended to use
>> in cases where there is only one variant? Or, for such
>> cases, has common useage become just to compare against the
>> corresponding APR_* constant (eg, APR_EOF)? Thanks very
>> much.
>>
>> --
>> best regards,
>> randy kobes
>>
>
>
>--
>Wesley W. Garland
>Director, Product Development
>PageMail, Inc.
>+1 613 542 2787 x 102
Re: advice on use of APR_STATUS_IS_*
Posted by "Wesley W. Garland" <we...@gmail.com>.
Aside from stylistic consistency, I can't see a compelling reason for
using the APR_STATUS_IS_* macro group -- and I think a viable case
could be made for avoiding them entirely for a fresh codebase. (For
example, I have 49,773 lines of apr-centric application code here...
and zero lines where APR_STATUS_IS_* appears).
If I was working on PERL APR:: bindings, I would choose whatever is
the best expression for the language. Not knowing PERL, I can't really
comment there.
For what it's worth, I feel fairly strong about using two types of return calls:
1. check against != APR_SUCCESS
2. check using switch() with a default: case
...and I really hate unnecessary macros.
But this is more of a religious discussion than an APR discussion, so
I won't expound further. :)
Wes
On 5/8/05, Randy Kobes <ra...@theoryx5.uwinnipeg.ca> wrote:
> mod_perl 2 supplies some APR::* modules for binding to apr,
> and a question has arisen regarding checking error codes
> against the appropriate APR_* constants. In apr_errno.h
> there are warnings about using the corresponding
> APR_STATUS_IS_* macros, as there could be more than one
> variant satisfying an error condition (eg,
> APR_STATUS_IS_ENOENT). There are a number of cases though
> for which at present there's only one such condition (eg,
> APR_STATUS_IS_EOF). What we were wondering is if the
> APR_STATUS_IS_* macros are still strongly recommended to use
> in cases where there is only one variant? Or, for such
> cases, has common useage become just to compare against the
> corresponding APR_* constant (eg, APR_EOF)? Thanks very
> much.
>
> --
> best regards,
> randy kobes
>
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Re: advice on use of APR_STATUS_IS_*
Posted by Joe Orton <jo...@redhat.com>.
On Sun, May 08, 2005 at 05:51:48PM -0500, Randy Kobes wrote:
> mod_perl 2 supplies some APR::* modules for binding to apr,
> and a question has arisen regarding checking error codes
> against the appropriate APR_* constants. In apr_errno.h
> there are warnings about using the corresponding
> APR_STATUS_IS_* macros, as there could be more than one
> variant satisfying an error condition (eg,
> APR_STATUS_IS_ENOENT). There are a number of cases though
> for which at present there's only one such condition (eg,
> APR_STATUS_IS_EOF). What we were wondering is if the
> APR_STATUS_IS_* macros are still strongly recommended to use
> in cases where there is only one variant? Or, for such
> cases, has common useage become just to compare against the
> corresponding APR_* constant (eg, APR_EOF)? Thanks very
> much.
Yes, it's recommended that the APR_STATUS_IS_* macros are used. In a
small set of cases where the error code is "invented" by APR like
APR_EOF, it doesn't really make any difference, but I suppose possibly
that could change in the future so better to be safe than sorry...
Regards,
joe