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