PATCH handle null cpplib buffer
Per Bothner
per@bothner.com
Fri Aug 29 15:55:00 GMT 2003
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/
More information about the Gcc-patches
mailing list