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.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.
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.
Kean
