ap_mmn.h breakage

[Rasmus Lerdorf <ra...@apache.org>]

This makes no sense to me:

/** @deprecated present for backwards compatibility */
#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_AT_LEAST old_broken_macro_we_hope_you_are_not_using

That MODULE_MAGIC_AT_LEAST #define is not doing anything for backwards
compatibility.  It simply breaks existing modules that use it.  And yes,
PHP uses it so the released version of PHP will not build with Apache
2.0.39.

-Rasmus

Re: ap_mmn.h breakage

[Greg Stein <gs...@lyra.org>]

On Wed, Jun 19, 2002 at 08:18:57AM -0700, Rasmus Lerdorf wrote:
> This makes no sense to me:
> 
> /** @deprecated present for backwards compatibility */
> #define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR
> #define MODULE_MAGIC_AT_LEAST old_broken_macro_we_hope_you_are_not_using
> 
> That MODULE_MAGIC_AT_LEAST #define is not doing anything for backwards
> compatibility.  It simply breaks existing modules that use it.  And yes,
> PHP uses it so the released version of PHP will not build with Apache
> 2.0.39.

The macro's logic was totally broken, making it useless. If you *are* using
the macro, then you've got problems.

AP_MODULE_MAGIC_AT_LEAST() is the proper macro.

And because people got the code kind of working with the old macro, when
they use the proper macro, their code might need to be tweaked. If we simply
nuked the macro, then somebody might insert AP_ at the start, thinking that
is the "right" thing to do, then have a bunch of code go wonky. With the
funny symbol in there, they will take a closer look and (hopefully) fix
things. Maybe more doc to that effect would be good. ?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: ap_mmn.h breakage

[Cliff Woolley <jw...@virginia.edu>]

On Wed, 19 Jun 2002, Rasmus Lerdorf wrote:

> #define MODULE_MAGIC_AT_LEAST old_broken_macro_we_hope_you_are_not_using

The released version of PHP is broken, and has been since the day we
bumped the MMN past the one that was used when the use of this macro was
initially committed.  I fixed this in PHP's HEAD a while back, but I dunno
if it's been MFH'ed yet.

> That MODULE_MAGIC_AT_LEAST #define is not doing anything for backwards
> compatibility.

Unfortunately, this was totally a lose-lose situation.  Somebody had to
get screwed no matter what course of action we took.

 - Had we left this macro alone, PHP would have been broken anyway because
it didn't account for the backward behavior of this macro (which was
semantically MODULE_MAGIC_AT_MOST rather than MODULE_MAGIC_AT_LEAST based
on its implementation).

 - Had we "fixed" this macro, it would have meant flipping the behavior of
any module that used it, and any module that had actually "successfully"
used it in the past would have had to already account for its backwards
behavior.

 - Had we deprecated the macro completely (which is what we did), it would
have broken compilation for everybody but in such a way that they wouldn't
be surprised by unexpected build failures, which is what would have
happened in either of the two cases above.


  We can't just go changing semantics on something like this just because
the old semantics were wrong, as it would have broken people who expected
the old semantics.  PHP was broken with the old semantics anyway because
it expected the "right" semantics rather than the actual ones.  All we can
do is start over with a new one.  This is the exact approach that was
taken by Apache 1.3 over two years ago, so the best we could do was match
that.  I believe I made the right choice.

--Cliff