It would be useful to have a comment clarifying what range of values this macro can safely be used for. I'm assuming it should be enough that it's valid for values in the range(-PyLong_BASE**2, PyLong_BASE**2).

Sorry, I think I was unclear. The(twodigits)x cast potentially loses information ifx is large enough, leading to the possibility of false positives forIS_MEDIUM_INT. For example, that will happen on Windows with a largePy_ssize_t value and 15-bit digits - in that case,Py_ssize_t is much larger thanunsigned long.

So there's some restriction on the value ofx for which this test is valid. "Fits instwodigits" would probably be enough, but I don't think we use this macro for values outside the range(-PyLong_BASE**2, PyLong_BASE**2).

More generally, C's integer-handling rules make this sort of thing horribly messy to reason about: for example in the 15-bit digit case the addition is an addition of anunsigned long to a (signed!)int, since the integer promotions will promote theunsigned shortPyLong_MASK to anint (though even that part is not guaranteed by the standard - there's nothing preventingshort andint having the same precision, in which casePyLong_MASK will be promoted tounsigned int instead ofint). So now we have to consult the rules for unsigned + signed addition in the "usual arithmetic conversions", which eventually say that becauselong has greater rank thanint (even if it has the same precision), both operands will be treated asunsigned long for the addition.

The2 * PyLong_MASK is another case that could end up being either signed or unsigned depending on ranks, types, etc; it's probably better spelled as2U * PyLong_MASK; that way we can at least be sure that it's performed as an unsigned multiplication and that the final comparison is unsigned-to-unsigned.

I'd suggest the addition of an extra cast around the result of the addition, just to reduce the number of mental hoops one has to jump through to establish that this really does give the right result: that is,

((twodigits)((twodigits)(x)+PyLong_MASK) <= 2U*PyLong_MASK)

We should also add extra parentheses around thex, in case someone tries to useIS_MEDIUM_INT on an expression more complicated than a single name.

I wholeheartedly agree that C's integer handling is a pain to think about 😞

For clarity I think this is best to use an inline function that makes all casts super explicit.
That way that it makes the cast explicit (if called with something other thanstwodigits orsdigits, the caller is responsible.

staticinlineintis_medium_int(stwodigitsx){/* We have to take care here to make sure that we are     * comparing unsigned values. */twodigitsx_plus_mask= ((twodigits)x)+PyLong_MASK;returnx_plus_mask< ((twodigits)PyLong_MASK)+PyLong_BASE;}

Does that seem sensible?

This should not have been changed. There's no guarantee that anunsigned long fits in something of typetwodigits. I'll open a bug report and make a PR when I get the chance.

Opened#30496. We seem to be okay on current platforms because fromlongintrepr.h,twodigits has type eitherunsigned long oruint64_t (depending onPYLONG_BITS_IN_DIGIT), and no platform we currently care about has along larger thanuint64_t.