On Tue, Jan 13, 2004 at 01:32:46PM -0500, Russell Yanofsky wrote:
> Greg Hudson wrote:
> >>> My input:
> >>> ...
> >>> * I'm waffling on what we should do with the svn_io APIs which
> >>> simply wrap APR functions. I think we want to fix those as well
> >>> (i.e. use svn_filesize_t), and then if APR ever gets a largefile
> >>> story we should be in a good position to make use of it.
> >> If APR gets a large filesize story, won't they just make the
> >> definition of apr_off_t 64 bits? If so, then we're already in a
> >> position to make use of it. Why complicate the wrapper functions if
> >> they are already portable?
> > If APR simply bashes apr_off_t on Linux to 64 bits, breaking ABI
> > compatibility, then by avoiding apr_off_t, at least our own ABIs won't
> > break, although that would be small consolation to apps which use APR
> > functions in addition to svn functions.
I don't know where you get the idea that there is something unique about
how Linux implements large file support: the kernel and glibc just
implement the LFS standard, http://ftp.sas.com/standards/large.file/.
It's the same in Solaris, HP-UX, AIX, UnixWare, and probably lots of
other non-BSD-derived Unixes.
> > If APR makes apr_off_t on Linux 64 bits for new compiles but uses
> > #defines so as to leave around 32-bit functions for old compiles (the
> > *BSD route), then by avoiding apr_off_t, our ABI won't break when it
> > otherwise would.
> > If APR makes apr_off_t 64 bits only when a special symbol is defined
> > (the Linux route), then we'll be free to define that symbol and get
> > 64-bit I/O without fear of breaking our ABI.
> I was assuming that APR would take the apr_off_t bashing route. Is this not
> a safe assumption?
Yes, the only sane way to get LFS support in APR is to define apr_off_t
as off64_t and internally use the transitional API (open64 etc). Having
APR export -D_FILE_OFFSET_BITS=64 would screw everything up just as much
as when Perl does it.
Currently, users can already choose a 64-bit apr_off_t on LFS systems by
building APR with -D_FILE_OFFSET_BITS=64, and changing the size of off_t
itself. (though APR wasn't choosing the correct APR_FMT_OFF_T in that
case until yesterday on HEAD)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 13 22:26:28 2004