Re: [Issue 639] - introduce svn_filesize_t

issues@subversion.tigris.org wrote:

>http://subversion.tigris.org/issues/show_bug.cgi?id=639
>
>
>
>
>
>------- Additional Comments From gstein@tigris.org 2003-03-17 18:00 PST -------
>Why does the patch use an unsigned type? When I looked into the
>problem, I figured that we should use a signed type (as explained in
>this issue).
>
>

Yes, I was thinking about that... here's what happens: We're using
apr_size_t to measure string lenghts and file chunk sizes. We do have to
compare those to svn_filesize_t in several places. Now, if the filesize
is signed, we get those signed/unsigned comparison warnings again, and
the only way to shut them up is with a cast.

Looking through the code, I didn't see a single instance where we'd
potentially need an invalid filesize constant. But in case we do, I
defined SVN_INVALID_FILESIZE to an all-bits-set value. We're not using
it anywhere yet, but it's there.

Or we could go the other way, and use a signed type for all memory
object sizes. But that would cause problems on the APR boundary, which
would require casting again.

Right now, the only compelling reason I see for using a signed filesize
type is for relative offsets. I can't see us needing those, but you
never know. Using an unsigned type was the safest compromise I could
come up with.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org