On Mon, Jan 12, 2004 at 02:10:23AM -0800, Ben Reser wrote:
> So I guess my suggestion at this point is to do the following:
> a) For exported interfaces do not use apr_off_t. Use apr_int64_t.
This is a good, general rule. A long while back, we came up with the idea
to use svn_filesize_t because we wanted to ensure that SVN could hold
large files, regardless of the underlying platform's capabilities. Of
course, it will obviously fail if it tries, but the APIs are in place to
be correct and "where it hits the road", we can compensate between SVN's
large file size and the platform specifics.
> c) Don't use apr_off_t for the line_no parameter of the blame receiver.
> I figure either unsigned long or apr_uint32_t. The former gets the
> advantage of scaling with 64-bit archs. Not that I think anyone is ever
> going to want to run blame on a file with more than 4 billion lines.
I'd go with apr_uint64_t rather than svn_filesize_t. This is a line number
rather than an offset/size of a file. Yes, the two are proportional to
some degree, but I'd agree with ghudson about the "mental judo" if we used
svn_filesize_t for that param.
> Since we're mostly only using apr_off_t as an output variable as opposed
> to an input variable this ought to be pretty safe. The one exception is
> svn_io_file_seek. Which would require the bounds checking to match APR.
> However, we might be able to ignore the bounds checking and just drop
> apr_io_file_seek, I don't see it being used anywhere.
I would seriously recommend dropping all svn_io_* functions from the Perl
bindings. In general, Perl itself has its own APIs to do that stuff (and
it does it in a Perl-standard fashion and is doc'd well and has precedent
and ...). Note that we already ignore a bunch of svn_io_ functions (see
core.i). I suspect there are a lot more svn_io_* functions that have been
added recently which need to be ignored, too.
Thus, I'd expect to see a patch which extends the list in core.i to
include a lot more functions. There are probably a good number more of
these across the subr functions.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jan 12 22:50:52 2004