This is the mail archive of the gcc-patches@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]

Re: preprocessor/14438


On Mar 24, 2004, Zack Weinberg <zack@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> 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.

> 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.

It turns out that the most common caller of _cpp_lex_direct(),
cpp_lex_token(), already takes care of that, and other callers seem to
take care of buffer management already, except perhaps for the code
that reads the initial file and directory name, but those should be
the first few tokens, therefore they should fall within the initially
allocated buffer and never fail.  I'm a bit wary of introducing
overhead in _cpp_lex_direct(), since it's quite performance critical,
and it appears that we're safe, so I'm leaning towards leaving it as
is.  If you agree, please go ahead and mark the bug as closed.
Otherwise, I suggest that you, being more familiar with the cpp code,
take it over and refactor it a big to make it safer without
introducing unnecessary overhead in the common paths.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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