apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Fri, 26 Mar 2004 07:10:47 GMT
On Thu, Mar 25, 2004 at 11:34:59PM -0600, William Rowe wrote:
> At 06:03 PM 3/25/2004, Joe Orton wrote:
> >On Thu, Mar 25, 2004 at 03:49:09PM -0800, Stas Bekman wrote:
> >> 
> >> That's a bad idea, IMHO, because ARP_HAS_LARGE_FILES will still report 
> >> false. You suggest to create a mess, where the library will report one 
> >> thing but behave as another.
> >
> >I was thinking about this today as well... what do you expect
> >APR_HAS_LARGE_FILES to actually mean?  "sizeof(apr_off_t) >
> >sizeof(apr_size_t)"?  or "sizeof(apr_off_t) > off_t"?  or
> >sizeof(apr_off_t)==8?  Any of these are trivial to implement in the
> >configure script.
> 
> .02 euro (worth more than US 2c) from the guy who invented the flag?
> 
> APR_HAS_LARGE_FILES means that an apr_off_t is bigger than
> all addressable memory (size_t).  You can't fit the apr_off_t into any
> [apr_][s]size_t placeholder.

Well, you may have invented it, but that's not what it does :)
APR_HAS_LARGE_FILES is always zero on Unix in 0.9.x currently, and yet
sizeof(apr_off_t) will be greater than sizeof(size_t) on the 32-bit
*BSDs with a 64-bit native off_t, similarly if built with
-D_FILE_OFFSET_BITS=64 on LFS platforms.

> Honestly I dont care if there is any relationship between óff_t and
> apr_off_t, otherwise why did we define our own type?  It's (possibly)
> an implementation dependent detail but otherwise irrelevant.
> 
> Bill
> 

Mime
View raw message