Joe Orton wrote: [...]
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.
Do you suggest that off_t is the only type that changes when LFS comes in?
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 }
That's actually a great idea, Joe! instead of relying on flags which may or may be wrong, compare the actual data types. The only issue I have is that apr_off_t is probably not the only data type that I need to check for possible collisions. Is that right? If so, that's why it's so much easier to have one define to do the check against and not all possible types, which may spring into existance post certain release.
So far I understood that relying on APR_HAS_LARGE_FILES is a bad idea, at least because you may be able to get more out of apr, but since the define may be unset, you won't be able to. Did I get it right?
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.
Yes, it defines both: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
