This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH handle null cpplib buffer
Per Bothner wrote:-
> >No, [need_line is] fundamentally a property of the buffer.
>
> Yes and no. It's *usage* is "we do not have a clean line
> so we need to call _cpp_get_fresh_line." This can have two
> causes: we need to (try to) get another line from the buffer
> *or* we're at the end. You may argue the latter is a special
> case of the former, but see below.
Hmm. I think it becomes necessary to have it as part of
the buffer to do #include right, but I'm happy to be proven
wrong.
> >Can't we revert your 08-21 rather than introduce this? I'm not
> >convinced from your 08-21 description that it was correct. I'm
> >concerned that this code might become something that only works
> >some of the time, and untangling it will be very hard.
>
> The problem is that old code never pops the "main" buffer.
> Obviously, the main buffer must be popped before a compile server
> starts reading a new main input file, and doing it as part of
> cpp_read_main_file is obviously ugly.
>
> Perhaps there should be a new cpp_close_main_file routine?
Perhaps - that's fine with me.
> A related issue: Processing of builtins including -D flags should
> probably be done *before* cpp_read_main_file. At least this the way
> the compile server currently does it. One reason is that logicallly
> the builtins and command line flags are not nested inside the main
> file - they are shared with other main files. Though we might
> re-consider that - after all stdio.h is also shared with other
> main files, and when a fragment the include history isn't quite
> right - if it matters. However, some _once initialization may
> depend on some command-line flags.
Right. I tried to do this about 18-24 months ago, but could never
get round the preprocessing of preprocessed input and the debug
issue.
> It's Labor Day weekend here, and I don't expect to be online again
> until Tuesday. Perhaps you could look at the compile server, and
> maybe come up with an alternative solution?
Sorry, I'm really short of time; I'm not even finding time to
work on the things I want to work on 8-)
Neil.