apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Sat, 27 Mar 2004 00:52:06 GMT
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message