This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Possible bug in GCC front end
- From: Nikola Ikonic <nikola dot ikonic at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 8 Feb 2010 15:09:54 +0100
- Subject: Possible bug in GCC front end
Hello all,
I have noticed something that is creating problems in my modified GCC,
and I see it as a bug, maybe I don't do something right. If you take a
look at cpp_interpret_string() function in charset.c you will see the
following part:
for (;;)
{
base = p;
while (p < limit && *p != '\\')
p++;
if (p > base)
{
/* We have a run of normal characters; these can be fed
directly to convert_cset. */
if (!APPLY_CONVERSION (cvt, base, p - base, &tbuf))
goto fail;
}
if (p == limit)
break;
p = convert_escape (pfile, p + 1, limit, &tbuf, wide);
}
and if you have a string that ends with "\\n", what will happen is the
following:
When p points to that last "\\", right before 'n' it p will be bigger
than base and smaller than limit for 1 (because p will be pointing to
"\\". p=convert_escape() will be called next with p+1 as one of the
arguments, which is OK, but convert_escape returns position for 1
increased, which means that after convert_escape() call, p will be
actually increased for two and there for be bigger than limit. But
there is no check for p bigger than limit, only p equals limit,
therefore loop will constantly call convert_escape. Therefore, I think
it would be better to have "p>=limit" instead of "p==limit". After
all, it does make no difference if we are checking that p is bigger
limit additionally to original condition. I hope I've contributed and
if not, I apologize for inconvenience.
Best regards,
Nikola