thanks Tim, for the partial enlightenment. :) Unfortunately my BTree/C-wisdom is much much smaller than yours, so I got to check a couple of assumptions over here. :)

Tim Peters wrote:
[Christian Theune]
Hah. Looks like BTrees can accept 2**31 on machines where maxint is a
larger ...

Note that "accept" in this case means "silently loses the
most-significant bits", and that's a BTree bug on platforms where
sizeof(long) > sizeof(int):


I was able to reproduce this on an Intel 64-Bit machine (EM64T) running Linux and gcc.

For one: I didn't see any compiler warnings. That sounds bad, right?

2**31 doesn't actually lose any bits when you store it, but it will
probably misinterpret the high-order data bit as the sign bit when you
fetch it again, magically changing it into -2**31.

I can store 2**31 in the BTree, but the keys() method will tell you that it actually stored -2**31.

As we hardcoded the search space to 2**31, I made the test check
whether btrees accept the number or not and differ in the expected results.
Should work on that 64bit machine now too.

Did you see my simpler suggestion for fixing the underlying bug (it
was a one-liner change to the original code)?  When you get tired of
fighting the 64-bit BTree bug here (it will be a minor miracle if the
test actually passes now on a 64-bit box, despite all you've tried
...), look that up ;-)

Nope, I didn't find your one-liner. :) Can you post it explicitly for my blind eyes?

I think I could have made up something that made it work, but I started looking into making the BTree behave sanely.

My idea was, to modify the BTree code in a way that it actually checks after the type cast whether the casted value is equal to the requested key, or alternatively try making the CHECK_KEY macro do an "exact type match" instead of allowing subclasses. But that wouldn't work either as 2**31 is still an int on those platforms. I'm a bit puzzled now. :)


gocept gmbh & co. kg - forsterstra├če 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to