On Tue, Jul 31, 2012 at 08:44:18PM +0200, Dmitry Pavlenko wrote:
> Hi all.
> I've noticed that in SVN 1.7 limit behaviour has changed. Is that expected or is that a bug?
>
> As I understand subversion supports revisions up to Long.MAX_VALUE = 0x7fffffffffffffffL =
> 9223372036854775807 > 1000000000000000 > 10000000000
>
> So both limits are possible thoeoretically. I ask because Java programmers often use Long.MAX_VALUE
> as "infinity" value instead of 0.
The limit value is defined as an int (see opt_state defitinion in
subversion/svn/cl.h). According to the C standard an int is always
32bit in size, and signed.
> $ $svn16 log http://localhost:59714/repos -l 10000000000
> ------------------------------------------------------------------------
> r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>
>
> ------------------------------------------------------------------------
> r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>
The 1.6 code uses strtol() without checking for overflow errors.
In the above case the large value you pass overflows and produces
some positive number within the range '[0, 2147483647]'.
Thus the limit is not 10000000000 (as you expect) but some other value.
> ------------------------------------------------------------------------
> $ $svn17 log http://localhost:59714/repos -l 10000000000
> svn: E205000: Non-numeric limit argument given
> svn: E200004: Number '10000000000' is out of range '[-2147483648, 2147483647]'
The 1.7 code uses the new-in-1.7 helper function svn_cstring_to_atoi()
to convert the limit argument from a string into an 'int' variable.
This function refuses to convert a string to a number if the string
does not encode a number within the range an 'int' can represent,
i.e. it checks for overflow errors and non-numeric character strings.
> Let's now try with larger limit:
>
> $ $svn16 log http://localhost:59714/repos -l 1000000000000000
> svn: Argument to --limit must be positive
This is an example where the strtol() overflow results in some negative
number.
I would say the 1.7 behaviour is better. You either get the specified
limit or an error, never some limit based on the result of overflow.
But I'm the person who made this change so I'm obviously biased :)
Received on 2012-07-31 21:26:55 CEST