apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Only ONE back-compat hole discovered.
Date Thu, 27 Jun 2002 04:03:17 GMT
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

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.

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.

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 :-)
 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              };
 93              #define APR_MEMNODE_T_SIZE APR_ALIGN_DEFAULT(sizeof(apr_memnode_t))

View raw message