Re: [PATCH] Fix PR preprocessor/15167

[Zack Weinberg <zack at codesourcery dot com>]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> I see nothing that would cause it to become true once again.  It is
>> only set to true in read_file_guts, which has already happened at the
>> point where _cpp_stack_file clears buffer_valid.
>
> But read_file is invoked in the comparison routine for each new instance that 
> is tentatively pushed!
...

I have now traced execution of your test case a bit and I see how this
is happening.

The bug you've found is just the tip of the iceberg, though.  Calling
read_file from this loop, for a file which is already on the stack,
clobbers the buffer for that file - which must not happen, because
that buffer is still being used by the lexer.  I suspect that we get
away with it because the block of memory holding the file contents is
not freed, and the lexer doesn't ever refer to file->buffer.  So it's
"just" a memory leak.  I think.

You can fix _this_ bug properly, I think, by splitting out the body of
that loop to a separate function that reads the file into a private
block of memory (*not* using read_file_guts - copy the inner loop) and
does the comparison from there.  I suspect we are gonna be in just as
much trouble from plain old recursive #include of a header with no
multiple-include guards whatsoever - but that's a very rare case, so
let's not worry about it now.  For 3.4 and 4.0 it will be enough to
fix the bug that someone has actually encountered, and for 4.1 this is
clear incentive for me to get off my ass and rewrite file lookup
and/or _cpp_clean_line.

zw