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.
My input:
* Because of the mess Linux (and Solaris?) have created, using
apr_off_t in our APIs is somewhat fraught. We can use #ifdef magic
to make our APIs work with both LARGEFILE and non-LARGEFILE callers,
but I bet we'd be happier without doing that.
* We have a type svn_filesize_t, which is always apr_int64_t. It
seems reasonable to use in our APIs where we want offsets (although
it requires a bit of mental judo to realize that the type which
holds file sizes is also appropriately large for holding file
offsets). See issue #639.
* 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.
* I can see no good motivation for using a 32-bit type in the blame
receiver callback. It introduces a type narrowing problem in the
blame implementation, even if it seems "unlikely" that there will
ever be more than four billion lines in a file. 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 12 17:24:08 2004