Re: DR handling for C++

[Gabriel Dos Reis <gdr@cs.tamu.edu>]

Matt Austern <austern@apple.com> writes:

| On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote:
| 
| > Dale Johannesen wrote:
| >
| >> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
| >>
| >>>   I think -fpermissive should just be removed.
| >>
| >> The eon SPECmark will no longer build if we do that.
| >
| > I suppose that's an issue, from a marketing perspective.  With my
| > customer-service hat on, I care a fair amount, as I have customers
| > who definitely want SPEC numbers.  With my GNU maintainer hat on, I
| > don't care as much.
| >
| > It may also be that eon requires a relatively small subset of
| > functionality presently allowed with -fpermissive.  It may also be
| > that if we do as I suggested (turn some pedwarns into errors, others
| > into warnings, leave others as pedwarns) that we would be OK because
| > the issues in question would become warnings, not errors.
| >
| > My problem with -fpermissive is only tangentially that it allows us
| > to compile bogus code; to me, the bigger problem is that it's yet
| > another knob, and one that is C++ specific.  I see no reason why the
| > basic warnings/errors/pedwarns structure from C should not also be
| > used in C++.
| 
| Isn't the fundamental problem that we're using pedwarns differently in
| the C and C++ front ends?  In the C front end you don't even see
| pedwarns unless you use a special compiler flag, and making them into
| errors requires an even more special compiler flag.  It's very odd
| that it means something so different in the C++ front end.

I guess, the issue is to give a meaning to pedwarn() in C++ that would 
require a special flag to behave as in C, without totally screwing up
the whole program.  I have been under the impression that most of the
cases where we use pedwarn() in C++ are those where we substantially
deviate from the standard.  I don't know whether the same is true for C.

-- Gaby