apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Date Wed, 31 May 2006 16:06:38 GMT
No, you entirely miss the point.

The HEADER tells the user who compiles against it, exactly what httpd
has or doesn't have.

If it doesn't have it, the fn returns NOTIMPL.  That's fine.

Your patch screws the user thusly;

mturk build says;  -DAPU_HAVE_ICONV=0

user's project says nothing...

   tests #if APU_HAVE_ICONV

   decides to enable feature X based on ICONV being present.

User runs his program which promptly crashes.

Thanks dude :)

Whatever the ***public*** headers say is what apr[-whatever] must be.

You can play these games in internal, private headers.  That doesn't matter.

Bill



Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>  > William A. Rowe, Jr. wrote:
>  >>
>  >> Shall we set up an appropriate perl/python/awk script which accepts
>  >> --with-iconv and can direct it at apr-iconv, libiconv for the gnuish
>  >> folk or something else altogether?
>  >
>  > Of course --without-iconv is one of those legitimate somethings ;-)
>  >
>  > But that results in an absolute
>  >
>  > #define APU_HAVE_APR_ICONV 0
>  > #define APU_HAVE_ICONV 0
>  >
> 
> Right, but in that case we have:
> #else /* !APR_HAS_XLATE */
> 
> APU_DECLARE(apr_status_t) apr_xlate_open(apr_xlate_t **convset,
>                                          const char *topage,
>                                          const char *frompage,
>                                          apr_pool_t *pool)
> {
>     return APR_ENOTIMPL;
> }
> 
>  > with no ambiguity.
>  >
> 
> And that's legitimate.
> In other case the apu build should fail I suppose.
> 
> Regards,
> Mladen.
> 
> .
> 


Mime
View raw message