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

Created on 2014-03-15 21:48 by Jeffrey.Walton, last changed 2022-04-11 14:58 by admin. This issue is now closed.

| Repositories containing patches | | | | | ------------------------------------------------------------------------------------ | | | | | http://hg.python.org/cpython | | | |

Messages (8)
msg213686 - (view)	Author: Jeffrey Walton (Jeffrey.Walton) *	Date: 2014-03-15 21:48
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?
msg213756 - (view)	Author: STINNER Victor (vstinner) *	Date: 2014-03-16 20:38
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 "", line 1, in OverflowError: timestamp out of range for platform time_t (where 0 means _PyTime_ROUND_DOWN)
msg213760 - (view)	Author: Gareth Rees (gdr@garethrees.org) *	Date: 2014-03-16 21:22
> 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.
msg213910 - (view)	Author: STINNER Victor (vstinner) *	Date: 2014-03-17 22:59
> 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.
msg317089 - (view)	Author: Martin Panter (martin.panter) *	Date: 2018-05-19 02:03
Maybe worth checking if this is fixed due to the changes in Issue 31373 for 3.6+.
msg317090 - (view)	Author: STINNER Victor (vstinner) *	Date: 2018-05-19 02:20
"resolution: out of date" Is this issue fixed or not? It's still open.
msg317091 - (view)	Author: Martin Panter (martin.panter) *	Date: 2018-05-19 02:38
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?
msg317278 - (view)	Author: STINNER Victor (vstinner) *	Date: 2018-05-22 13:33
I close the issue as a duplicate of bpo-31373. Reopen/comment bpo-31373 if the issue is not completely fixed.