[issue8013] time.asctime segfaults when given a time in the far future

Mandar Gokhale added the comment: [Strictly speaking, this is actually issue #10563, but that was marked superseded by the changes for this issue, hence the comment here.] The 5-digit year still displays an extra newline in Python 2.7.11 (there's extra whitespace on OSX as well, but that seems

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: Thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Committed in r87736. I opened a separate issue #10827 to address the lower bound. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Following Guido's response [1] to my inquiry on python-dev, I am attaching a new patch that makes time.asctime and time.ctime produce longer than 24-character strings for large years. [1] http://mail.python.org/pipermail/python-dev/2011-January/107187.

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: All tests pass and all works as documented with the latest patch on Ubuntu (glibc 2.11). -- ___ Python tracker ___ ___

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Attached patch, issue8013-pre-check.diff, checks for year range before calling system asctime and replaces a call to ctime with a asctime(localtime(..)). -- stage: needs patch -> commit review Added file: http://bugs.python.org/file20243/issue801

[issue8013] time.asctime segfaults when given a time in the far future

STINNER Victor added the comment: test_time fails with an (C) assertion error on Windows: see issue #10814. -- ___ Python tracker ___

[issue8013] time.asctime segfaults when given a time in the far future

STINNER Victor added the comment: > http://docs.python.org/library/time.html#time-y2kissues > "Values 100–1899 are always illegal." Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should at l

[issue8013] time.asctime segfaults when given a time in the far future

Changes by Shashwat Anand : -- nosy: -l0nwlf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: yes, sorry. what I meant to say is that fixing only upper bound for the year (according to CERT recommendation cited above) and leaving the lower bound in its current state is somewhat unsatisfactory. -- ___ Python tr

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Backported in r87664 (2.6), r87663 (2.7) and r87662 (3.1). Reopening to implement bounds checking for 3.2. Note that for time.asctime, checking the year range is trivial, but for time.ctime it is not because year is not computed in python code. One so

[issue8013] time.asctime segfaults when given a time in the far future

Andreas Stührk added the comment: It's documented under "Year 2000 (Y2K) issues": http://docs.python.org/library/time.html#time-y2kissues -- ___ Python tracker ___ _

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: I'm not sure that whether it's related to the current issue, but asctime doesn't seem to accept years < 1900. Which might be fair enough, has this been documented. -- ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl wrote: .. > I don't see the range checking as particularly challenging; I'm sure you can > get it done in time for 3.2. Will do. -- ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: > There is a long tradition in keeping OS functions' > wrappers thin with an expectation that application programmers will > know the limitations/quirks of their target OSes. Sorry, but that does not apply if we trigger undefined behavior which is inherently unsa

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: .. > My plan was to pick the low-hanging fruit (the null check) for 3.3 and s/3.3/3.2/ -- ___ Python tracker ___

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl wrote: .. > You cannot have both: a safe implementation and the correct behavior with > glibc > (not Linux!) -- except if you start special-casing.  Not sure that's worth it. > That's the reason why this and t

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: You cannot have both: a safe implementation and the correct behavior with glibc (not Linux!) -- except if you start special-casing. Not sure that's worth it. Note that time.asctime() is documented in time.rst to return a 24-character string, so what it current

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl wrote: .. > (What I mean is that overwriting \n or not, the code is unsafe, so the check > must be > done beforehand.  Why should that be left to 3.3?) Reading beyond a buffer is somewhat safer than writing,

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl wrote: .. > All right, then I wonder why your checktm() doesn't check the tm_year? It is not mine. I thought it did. I might have missed that when I reviewed the patch or there was a reason for that at the t

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: (What I mean is that overwriting \n or not, the code is unsafe, so the check must be done beforehand. Why should that be left to 3.3?) -- ___ Python tracker ___

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: All right, then I wonder why your checktm() doesn't check the tm_year? -- ___ Python tracker ___ ___ P

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:01 PM, Georg Brandl wrote: .. > > Since all implementations we have or can test have a defined behavior in one > way or the other, > I think an example of an implementation that exhibits such undefined behavior > is required fir

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: In that case however, it's equally unsafe to not replace a \n, but still use PyUnicode_FromString() without a size given -- you will read from random memory. Since all implementations we have or can test have a defined behavior in one way or the other, I think

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 5:35 PM, Georg Brandl wrote: .. > Both asctime() and ctime() fixed to remove newline no matter how many > digits the year has in r87657.  I also took the liberty of making the error > messages consistent. Georg, I disagree with yo

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: Tests fixed to ignore ValueError in r87656. Both asctime() and ctime() fixed to remove newline no matter how many digits the year has in r87657. I also took the liberty of making the error messages consistent. -- resolution: -> fixed status: open ->

[issue8013] time.asctime segfaults when given a time in the far future

STINNER Victor added the comment: > Sasha, commit is not working. I suppose that the fix for the segfault is correct. The problem on Linux is the new test: asc >>> import time; time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0)) 'Mon Jan 1 00:00:00 12345\n' asctime() of the GNU libc doesn't fail.

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: Sasha, commit is not working. It doesn't pass test on Ubuntu and returns the string with a trailing \n. Seems like that hunk of code is misplaced. -- nosy: +SilentGhost ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Committed in revision 87648. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky wrote: .. > Hmm. My search brought up issue 10563, but the last message on that > issue says that "a change has been recently made to time.asctime() to > reject year > .  See r85137 and issue6608."

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 1:52 PM, Alexander Belopolsky wrote: .. >> Well, then I would have no problem with checking for that condition >> beforehand and raising >> ValueError. >> > > IIRC, there was a similar bug report about ctime where pre-condition > c

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 10:52 AM, Georg Brandl wrote: .. > Well, then I would have no problem with checking for that condition > beforehand and raising > ValueError. > IIRC, there was a similar bug report about ctime where pre-condition checking was requ

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: Well, then I would have no problem with checking for that condition beforehand and raising ValueError. On the other hand, it seems that implementations either return a correct string or NULL, so just erroring out in case of NULL would be fine as well.

[issue8013] time.asctime segfaults when given a time in the far future

Andreas Stührk added the comment: Sorry, I meant " years > " of course. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue8013] time.asctime segfaults when given a time in the far future

Andreas Stührk added the comment: The real problem with years >= is that it is undefined behaviour anyway (see e.g. http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html: "the behavior is undefined if the above algorithm would attempt to generate more than 26 bytes of o

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: The patch is wrong: it hardcodes the number of characters that the time string has, but it can be more than 24 if the year is > . (Of course, the check for \n currently in the code is wrong too and must be fixed.) Also, shouldn't the issue be handled as in

[issue8013] time.asctime segfaults when given a time in the far future

Ned Deily added the comment: Thanks for the py3k patch. I am also attaching a refreshed patch for current 2.7. They both fix the segfaults when built and run on OS X 10.6 64-bit. Since the patches change timemodule to use asctime_r, which AFAICT is not used elsewhere in the standard librar

[issue8013] time.asctime segfaults when given a time in the far future

Andreas Stührk added the comment: Updated patch against py3k branch. -- nosy: +Trundle Added file: http://bugs.python.org/file20213/issue8013_py3k.diff ___ Python tracker ___ ___

[issue8013] time.asctime segfaults when given a time in the far future

Sandro Tosi added the comment: Hi Ned, thanks for the fast check! I tried to applied the patch (it failed, so it required a bit of manual editing) but when compiling I got: /home/morph/python-dev/py3k/Modules/timemodule.c: In function ‘time_asctime’: /home/morph/python-dev/py3k/Modules/timemo

[issue8013] time.asctime segfaults when given a time in the far future

Changes by Ned Deily : -- versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8013] time.asctime segfaults when given a time in the far future

Ned Deily added the comment: It's still a problem on OS X at least and is 64-bit related: $ arch -i386 /usr/local/bin/python3.2 -c 'import time;print(time.asctime(time.gmtime(1e12)))' Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform time

[issue8013] time.asctime segfaults when given a time in the far future

Sandro Tosi added the comment: Hi Alexander, can you confirm this bug is MacOs specific? I tried with python2.6 on a Debian sid @64 bit but I can't replicate it. Also, do you see it only on 2.6? if so, I doubt that it will ever be fixed; f.e. on release2.7 branch I have: Python 2.7.1+ (relea

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Looks like a case of missing null check. Patch attached. -- keywords: +patch nosy: +Alexander.Belopolsky Added file: http://bugs.python.org/file16359/issue8013.diff ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Wilfredo Sanchez added the comment: I get this on Python 2.6, not 2.5. And it seems to be limited to 64-bit. -- ___ Python tracker ___ __