apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: APR_HAS_LARGE_FILES and 64-bit builds
Date Thu, 16 Nov 2006 16:05:51 GMT
On 11/16/06, Joe Orton <jorton@redhat.com> wrote:
> On Thu, Nov 16, 2006 at 09:17:15AM -0500, Jeff Trawick wrote:
> > Should it be on or off?  IOW, should it mean that OS LFS support for
> > 32-bit apps such as fstat64() is used, or should it mean that APR can
> > handle large files?
>
> There was some discussion of this when the LFS stuff was going in,
> thread from msgid <20040320110426.GG11859@manyfish.co.uk>.
>
> I do think that the current definition is the probably the right one to
> be exposing as part of the API at preprocessor level, since it may be
> necessary to use at that level to be able to correctly interact with
> other libraries.  (mod_perl needs it like this, for example).
>
> Using sizeof(apr_off_t) should be sufficient for most cases where you
> need to determine simply "can APR handle file sizes > 2Gb" at compile
> time.

Something for the preprocessor would be nice.  sizeof() won't work and
_FILE_OFFSET_BITS seems ugly.

Index: testlfs.c
===================================================================
--- testlfs.c	(revision 475714)
+++ testlfs.c	(working copy)
@@ -31,7 +31,7 @@
 {
     ABTS_NOT_IMPL(tc, "Large Files tests require Sparse file support");
 }
-#elif APR_HAS_LARGE_FILES
+#elif _FILE_OFFSET_BITS > 32
 #define USE_LFS_TESTS

 /* Tests which create an 8Gb sparse file and then check it can be used

-/-

another ugly test:

APR_HAS_LARGE_FILES || APR_SIZEOF_VOIDP > 4

I don't see anything cleaner for 1.2 though*.

*a new symbol in trunk is possible

Mime
View raw message