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
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
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
Zope3-dev mailing list