perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
Date Fri, 22 May 2009 21:08:10 GMT
On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick <trawick@gmail.com> wrote:

>
>
> On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net
> > wrote:
>
>> Joe Orton wrote:
>> >
>> > Having thought about this longer, I do agree that it would be reasonable
>> > to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it
>> > turns out we're out of bits - allow_options_t is an unsigned char and
>> > we're using 2^0 through 2^7 already. :(
>>
>> The C langauge promotes char -> int for comparison.  256 should work fine,
>> no?  It would devolve to 0, of course, but 256 & 255 should test fine.
>>
>> Thoughts?
>
>
> Backing up a bit...
>
> I originally thought we could map bit values in 2.2.x to avoid affecting
> modules, but that isn't possible since includes-with-exec is two bits
> instead of one.
>
> Mapping OPT_INCNOEXEC to a no-op integer is something that takes place at
> compile time, and helps applications which reference the symbol but don't
> use it in any important way.  (IOW, let mod_perl and other similar tarballs
> compile.)  It is good in that it lets mod_perl compile, but bad in that
> mod_perl continues to export the Perl mapping of OPT_INCNOEXEC even after
> httpd has been upgraded and at some point later mod_perl is upgraded.
>
> Failing the compile is our only opportunity to catch some affected modules
> (though it is a rather late opportunity since the modules will likely be
> rebuilt later since they're supposed to work as-is when upgrading httpd;
> somebody will grumble though).
>
> I don't think we should try to preserve compilability if we can't preserve
> compatibility.
>
>
>>
>> > The only available option is to #define OPT_INCNOEXEC to some bogus
>> > string or something; not sure I like that much better than just a clean
>> > break.
>>
>
> /*
>  * #define OPT_INCNOEXEC  32
>  * Apache 2.2.12 and later no longer provide this.
>  * Applications which distinguish between includes-without-exec and
> includes-with-exec
>  * must use different logic for 2.2.<12 and 2.2.>=12.
>  * Prior to 2.2.12:
>  *   includes-without-exec: OPT_INCNOEXEC flag on, OPT_INCLUDES flag off
>

oops, both flags were on here


>
>  *   includes-with-exec:     OPT_INCNOEXEC flag off, OPT_INCLUDES flag on
>  * As of 2.2.12:
>  *   includes-without-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag
> off
>  *   includes-with-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag on
> *
> */
>

Mime
View raw message