| msg146793 - (view) |
Author: Florent Xicluna (flox) *  |
Date: 2011-11-01 16:52 |
| On builder "AMD64 FreeBSD 8.2 3.x" for the TIME_MINYEAR: ====================================================================== FAIL: test_negative (test.test_time.TestStrftime4dyear) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 397, in test_negative return super().test_negative() File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 425, in test_negative self.assertEqual(self.yearstr(TIME_MINYEAR), str(TIME_MINYEAR)) AssertionError: '2147483648' != '-2147483648' - 2147483648 + -2147483648 ? + |
|
|
| msg146818 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2011-11-02 00:28 |
| New changeset 9cb1b85237a9 by Florent Xicluna in branch 'default': Issue #13312: skip the single failing value for now. http://hg.python.org/cpython/rev/9cb1b85237a9 |
|
|
| msg146822 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2011-11-02 02:22 |
| New changeset d877d7f3b679 by Florent Xicluna in branch 'default': Actually, there's more than one failing value. (changeset 9cb1b85237a9, issue #13312). http://hg.python.org/cpython/rev/d877d7f3b679 |
|
|
| msg146828 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2011-11-02 07:09 |
| It fails for very low negative years: -2147483648 <= year < -2147481748 (-1<<31) <= year < (-1<<31) + 1900 Every other value behaves correctly on this FreeBSD buildbot: - (-1<<31) + 1900 <= year < (+1<<31) : correctly formatted with '%Z' - year < (-1<<31) : raises OverfowError - year >= (+1<<31) : raises OverfowError |
|
|
| msg146829 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2011-11-02 07:11 |
| I mean formatted with '%Y', of course. |
|
|
| msg146830 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2011-11-02 07:14 |
| New changeset 1a0bfc26af57 by Florent Xicluna in branch 'default': Issue #13312: skip the failing negative years for now. http://hg.python.org/cpython/rev/1a0bfc26af57 |
|
|
| msg220505 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-13 22:00 |
| The failing negative years test is still being skipped. I'm assuming this was not originally intended. |
|
|
| msg236981 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2015-03-01 21:37 |
| I believe that this can be closed as the test code was changed completely in #17960. |
|
|
| msg236985 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2015-03-01 21:45 |
| Mark, Issue #17960 ("Clarify the required behaviour of locals()") does not seem to be relevant here. I think you meant to refer to a changeset, not issue number. If so please use hash number such as d877d7f3b679. |
|
|
| msg236988 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2015-03-01 22:00 |
| As far as I can tell, the original report was about a test failing due to a system-dependent behavior of time.asctime(). However, since changeset 1e62a0cee092 (see issue #8013), we no longer call system asctime. I believe the test disabled in 1a0bfc26af57 can now be restored. |
|
|
| msg236989 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2015-03-01 22:03 |
| Sorry should have been #17690. |
|
|
| msg236993 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2015-03-01 22:30 |
| We still have the following in Lib/test/test_time.py: # Issue #13312: it may return wrong value for year < TIME_MINYEAR + 1900 # Skip the value test, but check that no error is raised self.yearstr(TIME_MINYEAR) I reviewed the current time.asctime() code and it does look like it invokes undefined behavior for extremely large negative years. The problem is that in C struct tm, year is stored as year - 1900 and for year < -2147481748 (= -2**31 + 1900) we trigger an overflow of a signed integer. Can someone confirm that on AMD64 FreeBSD subtracting 1900 from -2147483648 and then adding it back does not give -2147483648? |
|
|
| msg236994 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2015-03-01 23:07 |
| Attached patch eliminates undefined behavior, but I am not sure fixing this is worth the trouble. |
|
|
| msg270371 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-07-14 05:41 |
| If you enable GCC’s -ftrapv option, the subtraction overflow triggers an abort. Alexander’s patch works around the problem for asctime(), but the problem still exists in other cases, such as: >>> time.mktime((-2**31 + 1899, *(0,) * 8)) Aborted (core dumped) [Exit 134] Attaching a version of the patch without the conflicting whitespace changes. Why does Python even need to support such extreme time values? It would seem much simpler to raise an exception. |
|
|
| msg324026 - (view) |
Author: Gregory P. Smith (gregory.p.smith) * |
Date: 2018-08-25 01:08 |
| New changeset 76be0fffff8b7dbe649ad4821144461800ffb0d0 by Gregory P. Smith in branch 'master': bpo-13312: Avoid int underflow in time year. (GH-8912) https://github.com/python/cpython/commit/76be0fffff8b7dbe649ad4821144461800ffb0d0 |
|
|
| msg324038 - (view) |
Author: miss-islington (miss-islington) |
Date: 2018-08-25 05:53 |
| New changeset d5f017bbd65f37ac53fd3c6c439a53155eef2475 by Miss Islington (bot) in branch '3.7': bpo-13312: Avoid int underflow in time year. (GH-8912) https://github.com/python/cpython/commit/d5f017bbd65f37ac53fd3c6c439a53155eef2475 |
|
|
| msg324039 - (view) |
Author: miss-islington (miss-islington) |
Date: 2018-08-25 05:53 |
| New changeset c47acc2bb1d0a3fb6dda14ced958d272fb2821a6 by Miss Islington (bot) in branch '3.6': bpo-13312: Avoid int underflow in time year. (GH-8912) https://github.com/python/cpython/commit/c47acc2bb1d0a3fb6dda14ced958d272fb2821a6 |
|
|
| msg324040 - (view) |
Author: Gregory P. Smith (gregory.p.smith) * |
Date: 2018-08-25 05:54 |
| OverflowError is now raised for negative values that would trigger a problem and the unittest has been updated to test this. |
|
|
| msg324177 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2018-08-27 13:38 |
| Note for myself: Python 2.7 is not affected by this bug because it doesn't accept year < 1900. |
|
|