Re: [RFA] Fix preprocessor/6517

[Zack Weinberg <zack at codesourcery dot com>]

On Tue, May 21, 2002 at 11:40:14PM +0100, Neil Booth wrote:
> Neil Booth wrote:-
> 
> > If the preprocessor had a fatal error during option parsing,
> > it would set its error count appropriately, but the front end
> > was ignoring it (this goes back to 3.0; stand-alone cpp0
> > was always fine).  This patch causes errorcount to be set
> > in the C front ends appropriately after option processing,
> > and the compiler to exit if there are any errors after
> > option processing.
> 
> Incidentally, Zack, this patch makes DL_FATAL almost redundant,
> a good sign IMO.  All DL_FATAL are in cppinit.c, apart from
> one (recursive #include).  There are only two DL_ERRORs in
> cppinit.c, which have now effectively become DL_FATAL as
> far as cc1 is concerned, which are to do with stat issues
> other than "no such directory" for include paths.  Seems fine
> to me.
> 
> I think the semantics that clients bail out if there are errors
> after processing options, and continue otherwise are sound.
> Apart from polling, there is no easy way for a client to know
> whether a fatal error has occured (recursive #include is all
> that remains anyway).

Agreed.

Excessive #include nesting really shouldn't have been a fatal error in
the first place -- the important bit is that a potential infinite loop
gets aborted.  Which we already do by not calling _cpp_execute_include
in that case.

I'd suggest making the DL_FATAL instances in sanity_checks() into
DL_ICE instead of DL_ERROR.  The "I/O error on output" message, and
the inconsistent options messages, make sense as DL_ERROR.

zw