> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> Sent: 27 June 2002 06:03
Hi,
> 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:
#if !APR_BACK_COMPAT
... define macro to use sizeof ...
#else
... define macro to be function call that returns size ...
#endif
?
> 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...*
Thoughts?
Sander
