apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Solving the off_t problem in APR 1.0
Date Tue, 17 Feb 2004 19:15:12 GMT
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


View raw message