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
