Hah. Looks like BTrees can accept 2**31 on machines where maxint is a
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):
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.
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 ;-)
Zope3-dev mailing list