apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kean Johnston <...@sco.com>
Subject Re: Solving the off_t problem in APR 1.0
Date Wed, 28 Jan 2004 18:00:30 GMT
> That looks great: I'll commit your patch to the 0.9 branch unless there
> are any objections.  Thanks a lot for working on this issue.
My personal opinion is that its approaching the issue the wrong way. I 
think first and foremost, we need to establish why ABI compatibility 
with a 0.9 release is so important. I understand its desirable, dont get 
me wrong, but it *IS* a 0.9 release. I think people that use software 
that is undergoing radical change expect a certain amount of pain, and 
part of that pain is dealing with ABI changes.

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.

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.

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.


View raw message