[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_repos_trace_node_locations()

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-06-11 21:39:59 CEST

On Fri, 11 Jun 2004, [UTF-8] Branko Ä^Libej wrote:

> >>Sigh, I'm so tired of seeing people write these verbose comparison
> >>expressions... :-)
> >>
> >> return b - a;
> >>
> >>
> >
> >Don't we risk getting an over/underflow exception on platforms where such
> >things are signalled? Remember that these are signed numbers,
> >
> These are signed numbers that are guaranteed to be >= -1.

Where is that guarantee documented in the API? We have an official invalid
revnum, but SVN_IS_VALID_REVNUM works for the whole range of long int.
Also, many places just use SVN_STR_TO_REV, which in turn use plain atol.
Examples of this is in mod_dav_svn, so if we assume that revnums >= -1,
then this could be a security problem.

>
> >and the modulo 2 rule
> >
> Which rule is that?
>
I was referring to the rule that calculations with unsigned numbers must
be done as-if modulo some exponent of 2.

> >only applies to unsigned integral types if I understand the
> >C(++) standard correctly. But you seem to have ISO C available, so you
> >might be able to quote some paragraphs...:-)
> >
> >Please correct me if I'm wrong.
> >
> You're talking about the hypothetical case where b is positive, a is
> negative, and b - a > LONG_MAX. In this case, that can only happen if b
> == LONG_MAX - 1, and LONG_MAX is at least 2^31 - 1. I'd say we're fairly
> safe.
>
Crashes on any number in the range of an SVN_REVNUM_T are unacceptable.
Else we have to be more careful in the protocol implementations, which
might be a good idea anyway. But we aren't currently.

> But never mind, let's leave it as it is. At least whoever reads that
> will have fun figuring out the C operator precedence rules. :-)
>
I don't mind making others ha ve fun when I can...

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 11 21:58:38 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.