On Tue, 2004-06-08 at 21:56, Branko ÄŒibej wrote:
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(501) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(508) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(853) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(1284) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(2814) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(2817) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
> I think the representation size should be an svn_filesize_t, not an
> unsigned int, especially since it's generated using apr_atoi64 in many
> places.
It's not an unsigned int, it's an apr_size_t, which varies from platform
to platform. It's not like there's an ascii to apr_size_t conversion
function.
But you're right; the size and expanded_size fields of a
representation_t should be svn_filesize_t's, because of what they
represent. I will fix, but I can't find a gcc 3.2.3 option to warn
about implicit type narrowing, so I can't guarantee that I've fixed all
the warnings.
> C:\Home\brane\src\svn\repo\subversion\libsvn_fs_fs\fs_fs.c(3604) : warning C4018: '<=' : signed/unsigned mismatch
> strlen returns a size_t, not an apr_ssize_t.
C is such a bore some times. (int) -1 < (unsigned int) 3 evaluates to
0. In this case, the signed variable is always positive, of course, but
I can see why the warning exists.
> Hmm, and I see you're computing 'strlen(PATH_EXT_TXN)' three times in a
> loop. Premature optimisation may be the root of all evil, but we should
> at least /look/ like we're trying... :-p
I can't imagine this would ever cause a perceptible speed difference,
and therefore I would say it's wrong to compromise the code, even a
little bit, in the name of saving cycles. But in this case the code
also looks a little messy as a result of all those strlen() calls, so I
will change that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 10 01:27:47 2004