Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, Trundle, belopolsky, georg.brandl, l0nwlf, ned.deily, sandro.tosi, wsanchez
Date 2011-01-02.19:57:57
SpamBayes Score 1.03935e-09
Marked as misclassified No
Message-id <AANLkTimDOdZzHQGGrF+LYaM01U6vko-KE02_OB+9jz+i@mail.gmail.com>
In-reply-to <AANLkTin3eyiDOoO+LNdzONrdj_m3TRzYV1DJemVo4K=O@mail.gmail.com>
Content
On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
<report@bugs.python.org> 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 > 9999.  See r85137 and issue6608."  I wonder if that
> change made this issue moot.

It turns out the check added in r85137 does not cover tm_year even
though CERT recommends it (see msg107605).  These are separate issues
though. I think given where we are in the release cycle, the most
conservative solution would be to simply add a null check as follows.
(I did check that it fixes the crash on OSX.)

===================================================================
--- timemodule.c        (revision 87556)
+++ timemodule.c        (working copy)
@@ -620,6 +620,10 @@
     } else if (!gettmarg(tup, &buf) || !checktm(&buf))
         return NULL;
     p = asctime(&buf);
+    if (p == NULL) {
+        PyErr_SetString(PyExc_ValueError, "invalid time");
+        return NULL;
+    }
     if (p[24] == '\n')
         p[24] = '\0';
     return PyUnicode_FromString(p);
History
Date User Action Args
2011-01-02 19:58:01Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, l0nwlf
2011-01-02 19:57:57Alexander.Belopolskylinkissue8013 messages
2011-01-02 19:57:57Alexander.Belopolskycreate