In message <[EMAIL PROTECTED]>
Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Dec 2007, Tom Hughes wrote:
>
> >> I think it is a problem with the fast comparison. I've reproduced the bug,
> >> and when I added an explicit slow comparison function, it behaves
> >> correctly.
> >> I'll keep looking...
> >
> > I came to that conclusion as well, but had to go out before I had a
> > chance to send another mail.
> >
> > Thinking about it as I was walking to the station I suddenly realised
> > that the fast case comparison is treating the addresses as Word types
> > which are signed, so the high address in this case becomes negative
> > and appears to come before the other address.
>
> The thing is, as long as the comparison is always done the same way, it
> should work. The ordering won't be right if we treat the values as
> unsigned addresses, but they will be right if we treat the values as signed
> words.
>
> I thought I had reproduced the bug, but all I've reproduced is the
> unexpected ordering -- I can't actually get the assertion failure on the
> lookup.
I don't get the assertion until some more stuff has been added to
the tree - the reason is that although the tree is out of order that
node is at the root and is therefore found without having to decide
which way to go.
Only once it has been pushed down from the root by adding other things
do the lookups start to fail.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
