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: RFC: APR_LARGEFILE flag for APR 0.9
Date Fri, 26 Mar 2004 16:55:13 GMT
At 05:28 AM 3/26/2004, Joe Orton wrote:
>On Thu, Mar 25, 2004 at 04:44:02PM -0800, Stas Bekman wrote:
>> I expect a true value of APR_HAS_LARGE_FILES to mean "-D_LARGEFILE_SOURCE 
>> -D_FILE_OFFSET_BITS=64" on linux, and whatever are the equivalents are on 
>> other platforms (are they different or the same?) and whatever that implies 
>> for the type sizes.
>
>Hmmm.  I think it comes down to this:
>
>1. APR_HAS_LARGE_FILES is useless in APR 0.9.4 and earlier on Unix
>because it is never defined to 1 regardless of whether APR was built
>with _FILE_OFFSET_BITS=64.

No argument there, but it is useful on platforms which did implement it.

>2. APR_HAS_LARGE_FILES is not necessary in APR 0.9.5 and later on Unix
>because the size of apr_off_t as defined in apr.h does not change with
>_FILE_OFFSET_BITS.
>
>so I think you're right, the only useful definition for
>APR_HAS_LARGE_FILES is that it is 1 iff sizeof(apr_off_t) !=
>sizeof(native off_t).  I'd quite like to get input from the SVN crowd
>about this too.

Hmmm.  The useful definition is "ya, this build of APR knows how to play
with files >2GB."  This becomes especially critical in 1.0, iff we go with some
constant 64 bit file addressing across platforms.  Though in that case, some
dynamic test would be far more useful than a static, since both become
binary compatible.

Bill   


Mime
View raw message