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 Wed, 28 Jan 2004 19:03:00 GMT
On Wed, Jan 28, 2004 at 10:00:30AM -0800, Kean Johnston wrote:
> On a typical system that we are likely to care about today ... how many 
> things are actually using APR that cant be (and arent being) easily 
> updated? The two largest consumers of APR are Apache and SubVersion 
> right? SVN is chnaging daily, and Apache frequently enough that it is 
> unlikely to cause too much pain.

SVN is doing a 1.0 release in a month and we're in a freeze except for
critical issues.  We have apr_off_t's in our API.  We have run into
situations where our ABI breaks because of this.  We have two choices,
get this fixed in APR with a nice neat relatively simple fix.  Or start
making big ugly hacks in SVN to work around the problem.  Nobody really
likes the big ugly hacks that have been proposed.

This problem is indeed causing some pain for SVN and is indeed difficult
to fix in SVN directly.  This solution is simply the best solution to
the problem.

> But the question at hand ... as mentioned in the topic ... is what to do 
> with 1.0. If ABI compatibility in the 0.9 series is an absolute must, 
> the patch proposed will do, I guess. But for 1.0 I really think that 
> off_t should be 64 bits (or sensitive to _FILE_OFFSET_BITS - see below), 
> and APR does the required juggling inside itself to deal with non-LFS 
> system issues. Non-LFS systems are actually the easiest to deal with as 
> the largest file size and offset can always be expressed in a 32-bit 
> quantity to promoting the internal library type to 64 bits has no impact 
> on such systems.

Having coded an attempt to do just that in SVN I don't think it's a
simple as it sounds.  You can't feed numbers into a 32-bit system call
that won't fit in a 32-bit type.  If you do then you'll have all kinds
of odd behavior.  Which means you have to bounds check each and
everytime you make one of those calls.  It's not as easy to bounds check
as you one would think.

> One last word on this whole issue. I think it is reasonable for a 
> developer to expect to be able to use LFS as and when it needs to. Just 
> as users dont have to select a differnt libc when using LFS, they 
> shouldn't have to use a different APR. And APR should be suffuciently 
> size-agnostic that a developer can use it in one application without LFS 
> support and in another with it, with only, at worst, a -D option. It 
> seems like people have some kind of allergy to the _FILE_OFFSET_BITS 
> approach. I dont understand why. Its a perfectly reasonable way to 
> approach the issue. If APR was sensitive to such a macro, then any 
> fungling with 64-bit to 32-bit types is unnecessary. For all functions 
> in the library that accept or return an apr_off_t, you have _32 and _64 
> versions of them. Its not that hard really, and its even pretty clean. 
> At least doing that provides a consistant interface.

I agree that it would be nice to have such a setup with LFS when you
wanted it without rebuilding.  But that's not really the issue at hand
here.  Muddling this issue with LFS, I think just serves to confuse the
issue.  

The problem is pretty simple.  An application has no way of knowing how
big apr_off_t is as far as the APR library is concerned.  Which creates
a pretty nasty situation where an app can be expecting a 64-bit value
but APR only provides a 32-bit value.  

The proposed patch fixes only that problem.  It doesn't make an attempt
to solve LFS issues for APR.  That's something much bigger and more
difficult to solve.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org

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

Mime
View raw message