At 03:31 AM 2/17/2004, Ben Reser wrote: >On Wed, Feb 04, 2004 at 03:22:17PM +0000, Joe Orton wrote: >> On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote: >> > On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote: >> > > So I guess I'll look into redoing it to use int, long or long long >> > > instead. >> > >> > I found some time to look at this. The types I'm using now match the >> > formats we were using before. So we shouldn't have an ABI conflict. If >> > we do we had a bug with the formats already. >> > >> > The one case where this may exist would be 64-bit archs with 64-bit >> > off_t's. These platforms could use long long or long for the off_t. >> > They might choose differently than we have for apr_int64_t. I don't >> > know of any other way to deal with this than what was already done with >> > the LFS platforms that use long for off_t. We'll simply have to detect >> > these platforms one by one and apply exceptions for them. >> >> Alternatively, apr_off_t could be set to an integer type only on >> platforms where sizeof(int)==4: for real LP64 platforms (and those >> sizeof(int)==2 platforms which APR really doesn't build on anyway), just >> leave apr_off_t defined to off_t. >> >> This would be perhaps be simpler... > >I'm going to try and find time to look at this alternative solution >tomorrow. I want to have this "closed" in APR before we put out >Subversion 1.0.
I am against changing the default size or alignment of any data type in APR_0_9_BRANCH. If this [has] happened we break all binary compat. Good fix for APR 1.0 along with all the other problematic design decisions we made in 0.9's twisty and winding road. +1 for 1.0 Bill
