apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: Solving the off_t problem in APR 1.0
Date Tue, 17 Feb 2004 09:31:45 GMT
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.

Ben Reser <ben@reser.org>

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

View raw message