[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: Russell Yanofsky <rey4_at_columbia.edu>
Date: 2004-01-13 10:16:41 CET

Greg Hudson wrote:
> Well, Linux has certainly created a mess here. Pity they didn't go
> the *BSD route and actually wind up with a 64-bit off_t.

I agree with you here, but wow. This is from the same Greg Hudson that
expects the 1.0 subversion API to be supported 5 years from now? The one who
goes around saying that if a library isn't backwards compatible it might as
well not exist at all? :)

Then surely you can see that what this linux people did is pretty
reasonable. Instead of changing off_t from 32 bits to 64 when they
introduced 64 bit file I/O, they decided that making 64 bits default wasn't
worth breaking backwards compatibility over.

IMO, it is perl that is at fault here. It would be fine if perl just used
__USE_FILE_OFFSET internally to do 64 bit I/O on linux, but it has no
business imposing nonstandard library options on libraries that call into

> 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 the perl
> bindings
> have to be a little more complicated because perl can't handle
> 64-bit types gracefully, that's not a good reason to screw up the
> C API.

I agree here.

- Russ

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 13 10:14:03 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.