Re: PATCH handle null cpplib buffer

[Per Bothner <per at bothner dot com>]

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/