Issue 20941: pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'

pytime.c:184: runtime error: value -1e+200 is outside the range of representable values of type 'long'

   and

pytime.c:218: runtime error: value -1e+200 is outside the range of representable values of type 'long'

It appears the cast on 'intpart' is generating the finding. 'intpart' is a double.

    *sec = (time_t)intpart;
    err = intpart - (double)*sec;
    if (err <= -1.0 || err >= 1.0) {
        error_time_t_overflow();
        return -1;
    }

Shouldn't a range test based on TIME_T_MAX with an epsilon occur first?

Hi,

> pytime.c:184: runtime error: value -1e+200 is outside the range of representable values of type 'long'

How did you get this warning?

> Shouldn't a range test based on TIME_T_MAX with an epsilon occur first?

Two lines after, the integer overflow is checked:

        *sec = (time_t)intpart;
        err = intpart - (double)*sec;
        if (err <= -1.0 || err >= 1.0) {
            error_time_t_overflow();
            return -1;
        }

And it works, example:

>>> import _testcapi
>>> _testcapi.pytime_object_to_time_t(-1e+200, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t

(where 0 means _PyTime_ROUND_DOWN)

> How did you get this warning?

This looks like runtime output from a program built using Clang/LLVM with -fsanitize=undefined. See here: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

Signed integer overflow is undefined behaviour, so by the time *sec = (time_t)intpart has been evaluated, the undefined behaviour has already happened. It is too late to check for it afterwards.

> Shouldn't a range test based on TIME_T_MAX with an epsilon occur first?

What is this constant? I don't see it in Python source code.

Maybe worth checking if this is fixed due to the changes in Issue 31373 for 3.6+.

"resolution: out of date"

Is this issue fixed or not? It's still open.

I don’t know; I haven’t tested it. I was anticipating that it is fixed, but perhaps I should leave the resolution alone instead?

I close the issue as a duplicate of bpo-31373. Reopen/comment bpo-31373 if the issue is not completely fixed.

stage: resolved

superseder: demoting floating float values to unrepresentable types is undefined behavior