apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Only ONE back-compat hole discovered.
Date Thu, 27 Jun 2002 07:42:12 GMT
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: 27 June 2002 06:03


> Well, I did it today.  Plugged in libapr tagged APACHE_2_0_39 into an
> APACHE_2_0_35 and APACHE_2_0_36 libaprutil + httpd.  Of course
> we changed the bucket semantics and behavior too much to actually bring
> libaprutil up to the 2.0.39 rev.  This was a plug-in, binary compatibility
> experiment.

Ah... but, you are giving apr-util a different treatment as apr.  Why
should apr-util be allowed not to be back compat, when apr should not?

> And as they were fond of saying on the SCN Celebrety All Star Blowup...
> "She Blowed Up Real Good!!!"
> There was only -one- major problem, and we reveal, for the first time on
> this world-wide circulated devlist, exactly who the guilty party was!


> It all comes down to this, if you introduce a transparent type, you have
> doomed APR's backwards and forwards compatibility.  No bugs can
> be fixed, no hassles resolved.  You stick us, collectively, in the mud.
> As it was, I simply had to recompile the original libaprutil code against 
> the new 2.0.39 headers.  But after spending a s*load of time getting the
> 2.0.39 and forward releases compatible back to 2.0.35, this was a pretty
> stunning disappointment that we couldn't just drop in a current libapr.
> Fortunately, libhttpd did not require any rebuild at all.

I can already see where this is going...  It's about a certain dependency
between apr and apr-util, a dependency that httpd doesn't have.

> So it can be done if we all pull together to maintain binary compatibility.
> Platform specific faults can be eliminated by simply replacing the known
> good update for that platform.  No longer is an application doomed to
> being rebuilt.
> Of course, as we macro-enhance things, we tightly couple the app that
> uses those dirty macro wrappers to that version of the library.  This should
> become an optional feature, wherein the app author agrees that they will
> keep distributing apr and apr-foo libraries that their application was rebuilt
> against.  It isn't pleasant, but that's the price of faster interop with APR.

Are you suggesting something like a conditional:
   ... define macro to use sizeof ...
   ... define macro to be function call that returns size ...


> So now, as promised, the OGPs [official guilty parties].  This information is
> only now being revealed in hopes that the offending coders will pull this
> transparent type and illicit sharing of allocation sizes from the public headers, 
> and leave future generations with less risky declarations that won't break 
> binary compat :-)

The offending file is include/apr_allocator.h, a relative youngster, introduced
on 15 march 2002.

>  85                  apr_memnode_t *next;
>  86 striker  1.6     apr_memnode_t **ref;
>  87 jwoolley 1.3     apr_uint32_t   index;
>  88 striker  1.6     apr_uint32_t   free_index;
>  89 jwoolley 1.3     char          *first_avail;
>  90                  char          *endp;
>  91              };
>  92              
>  93              #define APR_MEMNODE_T_SIZE APR_ALIGN_DEFAULT(sizeof(apr_memnode_t))

The options on this are:

  1) move the parts of apr-util that are dependent on apr's private types to apr.
     [bucket allocator, which implies moving buckets to apr]

  2) loose the dependency altogether, ending the short life of, the current implementation
     of, the bucket allocator.

  3) I could have appended the new fields at the end of the structure.
     *slaps self for not having done that*
     Then, if we would choose to have a function to return the size of apr_memnode_t,
     instead of a macro, it would have just worked.  The only fields the bucket allocator,
     and any other allocator, rely on are first_avail and endp.  If we export that as
     a public type and have a private type with the rest of the fields, combined with
     a size function, we won't face this problem again.

  4) require apr and apr-util to be version dependent.
     *puts on asbestos suit...*



View raw message