[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-01-12 17:23:27 CET

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

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

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.