GeezerVison

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 if x is large enough, leading to the possibility of false positives for IS_MEDIUM_INT. For example, that will happen on Windows with a large Py_ssize_t value and 15-bit digits - in that case, Py_ssize_t is much larger than unsigned long.

So there's some restriction on the value of x for which this test is valid. "Fits in stwodigits" 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 an unsigned long to a (signed!) int, since the integer promotions will promote the unsigned short PyLong_MASK to an int (though even that part is not guaranteed by the standard - there's nothing preventing short and int having the same precision, in which case PyLong_MASK will be promoted to unsigned int instead of int). So now we have to consult the rules for unsigned + signed addition in the "usual arithmetic conversions", which eventually say that because long has greater rank than int (even if it has the same precision), both operands will be treated as unsigned long for the addition.

The 2 * PyLong_MASK is another case that could end up being either signed or unsigned depending on ranks, types, etc; it's probably better spelled as 2U * 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 the x, in case someone tries to use IS_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 than stwodigits or sdigits, the caller is responsible.

static inline int is_medium_int(stwodigits x)
{
    /* We have to take care here to make sure that we are
     * comparing unsigned values. */
    twodigits x_plus_mask = ((twodigits)x) + PyLong_MASK;
    return x_plus_mask < ((twodigits)PyLong_MASK) + PyLong_BASE;
}

Does that seem sensible?

This should not have been changed. There's no guarantee that an unsigned long fits in something of type twodigits. 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 from longintrepr.h, twodigits has type either unsigned long or uint64_t (depending on PYLONG_BITS_IN_DIGIT), and no platform we currently care about has a long larger than uint64_t.