This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor/14438
Alexandre Oliva <aoliva@redhat.com> writes:
> The reason why the patch had introduced a regression was that
> pfile->cur_token pointed to uninitialized memory, one past the last
> initialized token. _cpp_lex_direct() doesn't skip to the next line
> because we're processing a directive, so it just sets result->type to
> CPP_EOF, along with its correct location, after incrementing
> pfile->cur_token past result, without any form of initialization to
> this value. In fact, I'm a bit concerned as to what might happen if
> we were to call _cpp_lex_direct() an unlimited number of times while
> processing a directive; I don't see anything that would prevent
> cur_token from running past the memory area reserved for it.
Oh, ugh.
> I suppose one way to fix this issue would be to decrement cur_token
> again when returning in the CPP_EOF case, such that we'd return the
> same EOF token over and over; another would be to just refrain from
> dereferencing cur_token after reading an EOF token, but how would we
> tell? And, more importantly, why would we want to? Clearly we don't
> need it in the case I thought we did when I added the code I just
> removed; I don't think we need it elsewhere.
Suggest you add defensive code to prevent running cur_token off the
end of the buffer, as you suggest, and then go ahead and close the bug
report.
zw