You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test_time fails: strftime('%Y', y) for negative year #57521
Issue bpo-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.
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 bpo-8013), we no longer call system asctime. I believe the test disabled in 1a0bfc26af57 can now be restored.
# Issue python/cpython#57521: it may return wrong value for year < TIME_MINYEAR + 1900# Skip the value test, but check that no error is raisedself.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?
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:
Activity
florentx commentedon Nov 1, 2011
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 ? +python-dev commentedon Nov 2, 2011
New changeset 9cb1b85237a9 by Florent Xicluna in branch 'default':
Issue bpo-13312: skip the single failing value for now.
http://hg.python.org/cpython/rev/9cb1b85237a9
python-dev commentedon Nov 2, 2011
New changeset d877d7f3b679 by Florent Xicluna in branch 'default':
Actually, there's more than one failing value. (changeset 9cb1b85237a9, issue bpo-13312).
http://hg.python.org/cpython/rev/d877d7f3b679
florentx commentedon Nov 2, 2011
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:
florentx commentedon Nov 2, 2011
I mean formatted with '%Y', of course.
python-dev commentedon Nov 2, 2011
New changeset 1a0bfc26af57 by Florent Xicluna in branch 'default':
Issue bpo-13312: skip the failing negative years for now.
http://hg.python.org/cpython/rev/1a0bfc26af57
BreamoreBoy commentedon Jun 13, 2014
The failing negative years test is still being skipped. I'm assuming this was not originally intended.
BreamoreBoy commentedon Mar 1, 2015
I believe that this can be closed as the test code was changed completely in bpo-17960.
abalkin commentedon Mar 1, 2015
Mark,
Issue bpo-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.
abalkin commentedon Mar 1, 2015
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 bpo-8013), we no longer call system asctime. I believe the test disabled in 1a0bfc26af57 can now be restored.
BreamoreBoy commentedon Mar 1, 2015
Sorry should have been bpo-17690.
abalkin commentedon Mar 1, 2015
We still have the following in Lib/test/test_time.py:
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?
abalkin commentedon Mar 1, 2015
Attached patch eliminates undefined behavior, but I am not sure fixing this is worth the trouble.
vadmium commentedon Jul 14, 2016
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:
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.
gpshead commentedon Aug 25, 2018
New changeset 76be0ff by Gregory P. Smith in branch 'master':
bpo-13312: Avoid int underflow in time year. (GH-8912)
76be0ff
miss-islington commentedon Aug 25, 2018
New changeset d5f017b by Miss Islington (bot) in branch '3.7':
bpo-13312: Avoid int underflow in time year. (GH-8912)
d5f017b
miss-islington commentedon Aug 25, 2018
New changeset c47acc2 by Miss Islington (bot) in branch '3.6':
bpo-13312: Avoid int underflow in time year. (GH-8912)
c47acc2
gpshead commentedon Aug 25, 2018
OverflowError is now raised for negative values that would trigger a problem and the unittest has been updated to test this.
vstinner commentedon Aug 27, 2018
Note for myself: Python 2.7 is not affected by this bug because it doesn't accept year < 1900.