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
it.
> 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