Re: APACHE_2_0_BRANCH and APR

["William A. Rowe, Jr." <wr...@apache.org>]

At 12:35 PM 1/13/2003, Bill Stoddard wrote:
>There are two votes in the STATUS that deserve some on list discussion.
>
>    * APACHE_2_0_BRANCH uses a level of APR code branched from the
>      APACHE_2_0_43 tag.
>      yes:   trawick, jerenkrantz
>      no:    wrowe
>        wrowe observes that we have already finished substantial
>        bug fixing in 0.9.2-dev since APACHE_2_0_43, so branching
>        there seems arbitrary.
>
>
>    * APACHE_2_0_BRANCH uses a level of APR code versioned 0.9.2-dev
>        or later (to 0.9.9), so long it remains binary compatible.
>      yes:   wrowe
>      no:
>        wrowe suggests that when apr chooses to break compatibility,
>        httpd would continue to use that last compatible build.
>
>to the best of my knowledge, there is stuff in APR HEAD that breaks binary
>compatability. Bill Rowe, how do you plan to reconcile tihs with your vote? In
>principle, I agree that branching exactly at APACHE_2_0_43 might not be best
>because it does not pick up good fixes, but your alternative does not address
>the brokeness that exists now.

I've just committed the fixes to correct the binary breakage, while maintaining
Justin's desire to use unsigned over signed quantities.  I don't see those
as substantial breakage so we can move forward.

Those few applications that return > MAX_INT might appear as negatives to
applications that add too many elements, but I'm really not convinced that
you can even have more than MAX_INT queue or hash entries (or anywhere
near it) until you go to a 64P architecture with 64 bit pointers, 32 bit ints,
and those platforms are rare (Win64, and perhaps AIX or another one-off
unix.)  Unixes are generally 64 ILP if I recall correctly.

In any case, this moves us forward and if the apr list wants to argue for
domain sizes of such indexes in APR 1.0, now is a good time to start
discussing the advantages/disadvantages.

Bill