[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: apr_off_t is of an ambiguous size.

From: Joe Orton <joe_at_manyfish.co.uk>
Date: 2004-01-13 22:25:37 CET

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)

Regards,

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 13 22:26:28 2004

This is an archived mail posted to the Subversion Dev mailing list.