gh-97786: Fix compiler warnings in pytime.c

[mdickinson]

This PR fixes some compiler warnings in pytime.c, and at the same time fixes our out-of-range double-to-integer checks to properly avoid undefined behaviour.

It's hard to write strictly portable code for this kind of thing, but the new check should work under a set of (very) mild assumptions, that are highly unlikely to be violated on any actual platform that we care about:

• That time_t is a two's complement signed integer type with no trap representation. (The weakest part of this is the assumption that time_t is a signed integer type at all, but we're already making that assumption.)
• That _PyTime_t is also a two's complement signed integer type with no trap representation. (This is already true with the current typedef int64_t _PyTime_t; declaration.)
• That PY_TIME_T_MIN and _PyTime_MIN are within the range of a C double. These days we're assuming IEEE 754 binary64 doubles, so we're safe so long as the integer types _PyTime_t and time_t don't have a width of more than 1024.

Here's the underlying logic for the changes, for the record:

• We want to check that a C double value x is within the range of a (potentially unknown) signed integer type I with min and max values IMIN and IMAX. More specifically, we want to be sure that a conversion from x to type I will not invoke undefined behaviour; this means that the integer part of x (discarding the fractional part, if any) must be in [IMIN, IMAX].
• Assuming that I uses two's complement with no trap representation, IMIN must be the negation of a power of two, and IMAX == -1 - IMIN.
• So IMIN is exactly representable as a double (assuming that it's not larger than 2**1023), and (double)IMIN does not change the value.
• So the bottom-end check, (double)IMIN <= x, does exactly what we want it to.
• For the top-end check, x <= IMAX is problematic since the implicit conversion of IMAX to type double may change the value. But assuming that x is an integer (which it is for all cases in this PR), x <= IMAX is mathematically equivalent to x < (IMAX + 1), which with our two's complement assumption is equivalent to x < -IMIN, and we can express this as x < -(double)IMIN.

• Issue: Compiler warning for _Py_InIntegralTypeRange #97786

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @mdickinson for commit 32aee25 🤖

If you want to schedule another build, you need to add the :hammer: test-with-buildbots label again.

[mdickinson]

I've removed the fmod asserts from the code. They were somewhat obscure, and it's not necessary for correctness that the target value is an integer.

The only possible issue with a non-integer intpart is one of false positives: if intpart is a large and negative double in the open interval (PY_TIME_T_MIN - 1, PY_TIME_T_MIN) then:

• it's safe to cast intpart to time_t, since it's in range after discarding the fractional part, but
• the condition if (!((double)PY_TIME_T_MIN <= intpart && intpart < -(double)PY_TIME_T_MIN)) will be true, so an overflow would be reported

So the failure mode is benign. But in any case, intpart must be an integer (or possibly an infinity or nan), so the above can't happen.

[mdickinson]

I think this is ready to merge. @gpshead Do you have bandwidth for a quick re-review?

[miss-islington]

Thanks @mdickinson for the PR, and @gpshead for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11.
🐍🍒⛏🤖

[miss-islington]

Sorry, @mdickinson and @gpshead, I could not cleanly backport this to 3.10 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker b1b375e2670a58fc37cb4c2629ed73b045159918 3.10

[bedevere-bot]

GH-102062 is a backport of this pull request to the 3.11 branch.

[bedevere-bot]

GH-102150 is a backport of this pull request to the 3.10 branch.

[vstinner]

Thanks for fixing this old annoying compiler bug, @mdickinson!

[vstinner]

I added math.nextafter() and math.ulp() to Python 3.9 to help me to understand this issue :-) But then I failed to come up with a fix for this warning.

[mdickinson]

math.nextafter and math.ulp are very good to have, regardless! So thank you for that.