apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr STATUS
Date Thu, 11 Jul 2002 22:13:39 GMT
On Thu, Jul 11, 2002 at 01:37:14PM -0700, Brian Pane wrote:
> >Let's take a typical scenario:
> >
> >- Acme software releases mod_acme 2.0 to work with Apache 2.0
> >- They distribute a binary version of this module to work specifically
> >  with 2.0.39 (the only version out that isn't susceptible to the
> >  chunked-encoding vulnerability).
> >- Apache 2.0.40 is released, includes the new binary usec impl.
> >- Acme customers upgrade their servers to 2.0.40
> >- Acme customers experience all sorts of weird timing issues, "hung
> >  connections" (which are really just timeouts that were translated
> >  to busec's), etc...
> 
> I agree that this is a scenario that we need to avoid breaking.
> But changing the type name won't solve the problem: the run-time
> linker won't know the difference, since it doesn't know the types
> of fields inside structs or of function args.  I think the way to
> fix the binary problem is to just increase the MMN major number.

Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.

I'll agree that changing the typename doesn't solve the problem of
mismatched binary compatibility, but it does make it obvious to the app
author where the interface has changed. The renaming simply gives us
compile-time type-checking.

Maybe APR needs to have its own magic number. Is there a way to
make a version check mandatory, or are we stuck with a voluntary check?

-aaron

Mime
View raw message