[Christian]
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 everywhere.
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 bug. 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 absence. _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com