gh-123497: New limit for Python integers on 64-bit platforms

[serhiy-storchaka]

Instead of be limited just by the size of addressable memory (2**63 bytes), Python integers are now also limited by the number of bits, so the number of bit now always fits in 64-bit integer.

Both limits are much larger than what can be available on practice, so there is no effect on users.

_PyLong_NumBits() and _PyLong_Frexp() are now always successful.

• Issue: Impose new limit for Python integers #123497

[vstinner]

Overall, the change LGTM, but it would be easier to review and it may make more sense if splitted in 3 parts:

• change MAX_LONG_DIGITS limit and related changes -- maybe put long_rshift() and long_lshift() in this part
• change _PyLong_Frexp()
• _PyLong_NumBits() is always successful, bit_length(), bit_count(), etc.

[serhiy-storchaka]

Is it necessary? The PR is not so large and I can split it on even smaller part parts, but this is an additional work and is prone for errors. I can not guarantee that the intermediate state will be correct.

[vstinner]

uint64_t a_bits; cannot be greater than UINT64_MAX.

[serhiy-storchaka]

Yes, but it can be equal.

[vstinner]

LGTM. See also @erlend-aasland's coding style suggestions.

[serhiy-storchaka]

I have no idea what are the problems with building on Windows. Building locally fails with the same error, but running the reported command manually succeeded. And it seems that _PyLong_NumBits() is not even called during the run.

[serhiy-storchaka]

Fixed building on Windows. MAX_LONG_DIGITS was incorrectly set on 32-bit platforms.

#123724 is an alternative PR that uses int64_t instead of uint64_t for bit counts.

capi-workgroup/api-evolution#52 is a discussion about using unsigned or signed types. I have no strong preferences, although the code with unsigned types is slightly simpler (bit count is non-negative by its nature).

[vstinner]

LGTM

[vstinner]

capi-workgroup/api-evolution#52 is a discussion about using unsigned or signed types. I have no strong preferences, although the code with unsigned types is slightly simpler (bit count is non-negative by its nature).

In terms of the implementation, I prefer unsigned, it avoids to check if a number is negative by design (even for assertions). So, what do you choose?

[serhiy-storchaka]

Merged the signed version instead.