This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
your recent patch to cpplib.c
- To: mark at codesourcery dot com
- Subject: your recent patch to cpplib.c
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Tue, 8 Feb 2000 14:12:59 -0800
- Cc: gcc at gcc dot gnu dot org
I didn't see a gcc-patches message for this:
2000-02-07 Mark Mitchell <mark@codesourcery.com>
* cpplib.c (cpp_get_token): Call CPP_BUMP_LINE after reading a
carriage return after a macro name.
===================================================================
Index: cpplib.c
--- cpplib.c 2000/02/06 23:46:18 1.108
+++ cpplib.c 2000/02/07 21:34:39 1.109
@@ -2624,6 +2624,7 @@ cpp_get_token (pfile)
{
if (c != '\n')
break;
+ CPP_BUMP_LINE (pfile);
FORWARD (1);
}
else
There's a real bug, and the change may have appeared to be obviously
correct, but it wasn't.
What you don't see in the diff is that this is inside a loop which has
a mark set in the buffer. The mark does _not_ remember the line
number or the column base. This isn't a problem in the other two
places where marks are used, because we always go back to the mark and
process the text normally. But in this part of the code, we might go
back and we might not. You will always get the line number wrong in
one branch or the other. The patch just switches the bug to the less
common case, which is okay, but not a complete fix.
The right fix is not to use the mark at all in this context. It's
supposed to be for lookahead under extremely limited circumstances and
this isn't one of them. (And it will probably vanish entirely in the
parser rewrite.)
On the other hand, congratulations; you have probably found the line
numbering bug I've been looking for for months.
zw