perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
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 20:21:17 GMT
On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr.

> 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

> > 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
 * 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
 *   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

View raw message