On Mon, Jan 12, 2004 at 11:23:27AM -0500, Greg Hudson wrote:
> * 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.
*nod*
> * 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.
Pretty much the same issue then. Sounds like the job didn't get
finished. svn_filesize_t works for me. If we think it's too much judo
we can always typedef svn_offset_t to svn_filesize_t.
> * 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.
*nod*
> * 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.
Well I didn't see a motivation for a 64-bit int. All line_no is a
counter that gets incremented with every call. I have no problem using
a 64-bit int or doing the tiny (and I mean tiny) workaround to make it
work nicely on various perl versions. I'll be more than happy to
implement it as a apr_uint64_t if that's what people want.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 12 18:40:41 2004