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: svn commit: r589910 - in /apr/apr/trunk: CHANGES configure.in
Date Tue, 30 Oct 2007 00:14:45 GMT
Before I backport, I want to quickly test the temperature of the list...

wrowe@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=589910&view=rev
> Log:
> Radical change that corrects a horrible misassumption; the feature
> APR_HAS_LARGE_FILES means that we support offsets larger than memory
> could contain.  An audit of the code reveals no functional changes
> in the compilation of the library.  The testlfs.c source proves that
> this is the assumption of the users of this 'undocumented feature'.
> In fact, it's not possible to properly determine this publicly to
> adjust testlfs.c based on any other public symbol from the library.

If you study testlfs.c, we assume an 8gb file is nothing but an aspect
of having APR_HAS_LARGE_FILES.  Fine, that's what I always assumed too.
Win32 explicitly defined this forever because we use >size_t apr_off_t's.

Unix obviously failed to do this forever, and many platforms have never
tested testlfs.c, rendering that test bogus.

>  Changes for APR 1.3.0
> +  *) Corrected for Darwin and others to toggle APR_HAS_LARGE_FILES
> +     where large off_t's are enabled without any extra defines, hints
> +     or additional functions.  This is binary compatible, but apps
> +     may need to be recompiled to take full advantage depending on how
> +     they detect this feature.  [William Rowe]
> +

> --- apr/apr/trunk/configure.in (original)
> +++ apr/apr/trunk/configure.in Mon Oct 29 16:32:59 2007
> @@ -1413,6 +1413,10 @@
>      # Enable LFS
>      aprlfs=1
>      AC_CHECK_FUNCS([mmap64 sendfile64 sendfilev64 mkstemp64 readdir64_r])
> +elif test "${ac_cv_sizeof_off_t}" != "${ac_cv_sizeof_size_t}"; then
> +    # unsure of using -gt above is as portable, can can't forsee where
> +    # off_t can legitimately be smaller than size_t
> +    aprlfs=1
>  else

are we ok with this implementation or do folks have better ideas?

Finally, testlfs.c itself, now that we can (generally) compute CSIZE
everywhere, would let us test if a small sample test file of 1siMB + 1
byte actually occupies that much space, and bail if not.  If the CSIZE
becomes 2siMB or greater, we should further assume that this is a silly
FS that probably does provide sparse allocation but who's storage mult
is so large we won't measure it.

If that test sounds rational, this could become APR_HAS_SPARSE_FILES for
apr 1.3.0 only.

Both win32 previously, and darwin 9 now using HFS+, suck up 8GB of real
storage, which is (obviously) not acceptable - it's gotta be fixed before
we tag and roll 1.2.x.


View raw message