apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: RFC: APR_LARGEFILE flag for APR 0.9
Date Fri, 26 Mar 2004 11:28:04 GMT
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

Mime
View raw message