apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@apache.org>
Subject Re: cvs commit: apr STATUS
Date Thu, 11 Jul 2002 19:57:43 GMT
On Thu, Jul 11, 2002 at 02:35:04PM -0500, William A. Rowe, Jr. wrote:
> In this case, semantic compatibility has NO IMPACT on binary
> compatibility.  The code will remain binary compatible, even though
> this change breaks the behavior.
> APR changes... we are pre-1.0 and our developer/consumers know it.
> The only SEMANTIC argument for a different name is Roy's observation
> that time_t v.s. apr_time_t confuses users into trying to directly set
> seconds instead of apr_time_t units.  That's an argument I haven't
> bought into, but it is a legitimate argument.

The problem is that it used to be completely valid to treat apr_time_t
as a 64bit decimal integer quantity. Suddenly we are revoking that
assumption, without effecting some sort of source-level change that
will make the change obvious. Unfortunately for our users, the compiler
will happily validate this code, even though the semantic has changed,
and the user will not be notified of a potential problem.

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


View raw message