Tim Peters wrote:
Thanks for the clarification, Tim!
You're welcome :-)
Due to the possible future use of 64-bit BTrees, I'm inclined to go for
the 2-character fix for now and possibly remove it once we hit 64-bit
Yupp. If we remember ... ;)
The BTree bug and the intid bug are quite distinct. intid should be
repaired regardless, and is easy to repair. The only reason the BTree
bug got sucked into this is because an overly-elaborate way of
repairing the intid bug bashed into the BTree bug (the elaborate initd
fix reasonably assumed that Ix BTrees would complain if you tried to
store a key they can't actually handle, but in fact they don't always
complain). All the _simple_ ways of repairing intid avoid the BTree
Which is ok with me ... and is what I did.
In a 64-bit-everywhere world, presumably intid will want to change to
use an id range substantially larger than 31 bits anyway.
BTW, note that the simple intid fixes are essentially untestable, and
for the same reason you can't actually write a convincing test now
that _shows_ that the current (pre-patch) intid is buggy. There are
only 2 return values (out of 2**31+1 current possible outcomes) that
create a problem, so it's a one-in-a-billion chance of screwing up.
The simple fixes just remove (exactly) those two problem cases. It's
trivial to prove that the current intid has that bug, and
substantially harder to prove that the 2-character fix repairs it (but
trivial to prove that my original suggestion repairs it), but it's
very much harder to write a test showing either the bug or its
Right. The test that I wrote merely checks that the border case of
2**31-1 is applied correctly and assumes all smaller numbers to work
This finally works on 32- and 64-bit machines.
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