This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]