This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH handle null cpplib buffer
Neil Booth 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.
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?
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.
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?
--
--Per Bothner
per@bothner.com http://per.bothner.com/