splitting up cpplib, revised

Zack Weinberg zack@rabi.columbia.edu
Tue Oct 27 11:13:00 GMT 1998


On Tue, 27 Oct 1998 11:56:25 -0500, Dave Brolley wrote:
>Zack Weinberg wrote:
>
>> In the meantime, here's another patch.  This one is pure bugfix: it
>> makes -include work properly when cpplib is linked into cc1.  The
>> problem was that cpp_start_read was processing the -included file
>> through to the token_buffer, but c-lex.c didn't expect anything to be
>> in the token_buffer until after cpp_get_token had been called for the
>> first time.
>>
>> The change in init_parse fixed that, but then another bug appeared in
>> the nesting of #line directives.  The only way to cure that was to
>> pretend that -included files were pulled in by a chain of #include
>> directives.
>
>What was the new bug and why was the "only" way to fix it to simulate
>a stack of #include directives, as opposed to a sequence of them?

This is fairly complicated.

cpp_start_read isn't supposed to produce any tokens for the compiler
proper.  c-lex expects to have to call cpp_get_token at least once
before there's anything in the token buffer.  You can hack around that
but it's ugly and inefficient.  So for -include, you want to put the
files in a place where they'll be read later.  That's the buffer
stack.  The buffer stack doesn't do sequences.  If you try, you end up
with no enter_file #line commands for the -included files, and c-lex
doesn't like that.

-imacros doesn't have this problem since any non-directive text of the
file is discarded.

>Does the direction of the discussion started by Per's reponse make
>this patch obsolete now?

No.  Per's talking about a long-term goal.  Near term, we need to get
cpplib to the point where it can replace cccp as a stand-alone
preprocessor, and this fixes an important problem with that.

>I would also like to point out that you will probably have to make
>similar changes to cp/lex.c regardless of what the final patch looks
>like.

Right, I'll try to get that this evening.

zw



More information about the Gcc-patches mailing list