On Thu, Mar 25, 2004 at 04:44:02PM -0800, Stas Bekman wrote:
> Joe Orton wrote:
> >On Thu, Mar 25, 2004 at 03:49:09PM -0800, Stas Bekman wrote:
> >
> >>Jeff Trawick wrote:
> >>
> >>>(Related trivia: Maybe README.dev needs notes on large file support,
> >>>starting with the basic Unix requirement you outlined in a PR yesterday
> >>>
> >>>export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> >>>./configure
> >>>
> >>>and then having folks add comments on platforms where it has been tested
> >>>and/or where there are special considerations.)
> >>
> >>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.
>
> 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.
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.
> Since I have to glue perl and apr, I want to be able to say:
>
> seek file, pos, whence
>
> and non-zero pos and whence passed correctly from/to the C(Perl)/C(APR)
> side. If we have a disagreement in type lengths things go randomly broken
> and lots of hair gets lost.
The problem which causes serious alopecia is the disagreement between
the apr_off_t exposed by apr.h when mod_perl is built with
-D_FILE_OFFSET_BITS=64, and the apr_off_t *when APR was built*.
Since 0.9.5 works round this problem, it's now simple to cope with a
sizeof(Off_t) != sizeof(apr_off_t) in mod_perl; you just need to do
thunk between the two any place they are used together.
if (sizeof(apr_off_t) == 4 && sizeof(Off_t) == 8)
croak if offset > LONG_MAX
etc
}
> >>>From below I take it you really want "sizeof(apr_off_t) > off_t"?
> >That is consistent with what APR implements for Netware and Win32.
> >
> >It's inconsistent in that for e.g. FreeBSD or any 64-bit Unix, you get
> >"large files" by default courtesy of a 64-bit off_t, yet
> >APR_HAS_LARGE_FILES would be 0.
>
> I think that's fine. Since in that case USE_LARGE_FILES will be false, no?
> and perl and apr will agree on the type lengths. Am I correct?
If Perl only defines USE_LARGE_FILES when it defines
_FILE_OFFSET_BITS=64, then yes.
joe
