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: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Date Wed, 06 Jun 2007 21:31:44 GMT
Davi Arnaut wrote:
> William A. Rowe, Jr. wrote:
> 
>> But no, we should probably figure out how to report this case more
>> intellegently in testlfs so people don't panic.  LARGE_FILES, imho,
>> should not be set where special handling of the file offsets didn't
>> happen.
> 
> I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64
> bits long apr_off_t, because that's probably what the user want to know
> -- if the platform supports large files, which is true for 64 bit
> systems. 

What is large?  If on a future platform, if off_t (which -is- largely
portable, like ssize_t, just came a little after size_t) is 128 bits and
size_t is 64 bits, that's going to require exception code again.

You are reading APR_HAS_LARGE_FILES as APR_OFF_T_IS_64BIT, but this really
is not true.  The flag LARGE_FILE to the apr_file_open tells the system
that you want to open the classic apr_file_t (in apr 0.9) in a mode where
it will handle offsets > size_t bytes wide.

LARGE_FILES tells us that a generic int/void* union will not hold the
offset into a file, and this isn't true of most 64 bit builds.

> On 32-bits with LFS we should define an internal macro for
> special handling of the file offsets.


> For example, testlfs.c is perfect
> fine and should run on 64 bits platforms.

This is trues

> Although not a urgent issue, we should clarify and document better the
> APR_HAS_LARGE_FILES meaning.

+1, after we figure out what that is:0

Mime
View raw message