Re: egcs-1.1.1 stuff

[Joe Buck <jbuck at synopsys dot com>]

> > The C++ spec does not talk about errors and warnings. Instead, it
> > requires that an implementation should produce *diagnostic
> > message*. It is implementation-defined what constitutes these
> > diagnostics. For g++, diagnostics include error and warning message.
> > 
> > As Jason points out, -pedantic-errors turns warnings into errors.
> 
> At the very least, please provide a specific option to reject undeclared
> functions.

The main problem isn't what we call the problem (error or warning).  The
problem is that the parser inserts a definition of an undeclared function
as

	extern "C" int funcName(...);

The problem is that this is 99.9% certain to be incorrect, unless
the program is being written by a K&R C programmer who is just learning
C++.

It has implications for error recovery.  If funcName is a typo, then
a large cascade of bogus error reports will occur in many cases; these
bogus errors would not occur if this definition is not inserted and
an error node is inserted instead.  This especially happens with

	overloadedFunction(funcName());

where overloadedFunction does not accept an int argument.

Changing the status from warning to error, but still inserting the
extern "C" int definition, would be just as bad.  The problem is that
this K&R C notion (that you can use any name as a function and the
compiler will create a function returning int) is just wrong for C++
and should be killed dead (or at minimum there should be a flag that
does it).