This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients ajaksu2, akuchling, belopolsky, benjamin.peterson, brett.cannon, georg.brandl, kristjan.jonsson, loewis, meador.inge, skrah
Date 2011-02-04.17:35:36
SpamBayes Score 1.9060309e-12
Marked as misclassified No
Message-id <>
In-reply-to <>
On Fri, Feb 4, 2011 at 11:35 AM, Georg Brandl <> wrote:

>.. But seeing the history of this case, I don't want to play around here before 3.2 final.

Here is my understanding of the history of this case:  tmp1.patch was
applied in r65539 and reverted in r65543 with the log entry saying:

r65543 | andrew.kuchling | 2008-08-04 22:05:23 -0400 (Mon, 04 Aug 2008) | 1 line

#3367: revert rev. 65539: this change causes test_parser to fail

Revision 65539 has never been applied to py3k, but it would be
equivalent to the following diff:

Index: Parser/tokenizer.c
--- Parser/tokenizer.c	(revision 88320)
+++ Parser/tokenizer.c	(working copy)
@@ -1289,7 +1289,7 @@
     register int c;
     int blankline, nonascii;

-    *p_start = *p_end = NULL;
+    tok->line_start = *p_start = *p_end = NULL;
     tok->start = NULL;
     blankline = 0;

Applying the above diff now makes test_parser crash on a debug and
fail on a regular build.  The problem with initializing
tok->line_start to NULL is that doing so trades one undefined behavior
for another: pointer comparison such as a >= tok->line_start is only
defined if both pointers point to the same buffer.  Ordering between
NULL and non-NULL pointers is undefined.  My patch does not have this
issue because it initializes tok->line_start to tok->buf.
Date User Action Args
2011-02-04 17:35:38belopolskysetrecipients: + belopolsky, loewis, akuchling, brett.cannon, georg.brandl, kristjan.jonsson, ajaksu2, benjamin.peterson, skrah, meador.inge
2011-02-04 17:35:36belopolskylinkissue3367 messages
2011-02-04 17:35:36belopolskycreate