Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3D2DEC7A.4040903@apache.org>
Date: Thu, 11 Jul 2002 13:37:14 -0700
From: Brian Pane <brianp@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: cvs commit: apr STATUS
References: <20020711191053.2995.qmail@icarus.apache.org>
 <20020711191053.2995.qmail@icarus.apache.org>
 <5.1.0.14.2.20020711143150.02700ce8@pop3.rowe-clan.net>
 <20020711195743.GX18710@clove.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Aaron Bannert 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.

--Brian