This is the mail archive of the
mailing list for the GCC project.
Re: DR handling for C++
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Matt Austern <matt at lafstern dot org>,Nathan Sidwell <nathan at codesourcery dot com>,Jason Merrill <jason at redhat dot com>
- Date: 20 Sep 2004 15:40:58 -0500
- Subject: Re: DR handling for C++
- Organization: Texas A&M University, Department of Computer Science
- References: <414F37E0.firstname.lastname@example.org>
Mark Mitchell <email@example.com> writes:
| I've been asked to provide my input on the handling of DRs in the C++
| front end.
Historically, we have not been that methodoligical -- in the C++
front-end. I believe part of the confusion comes from the fact that
library policies were being discussed within the comments on Matt's
| Unfortunately, I don't have the messages from the original thread, so
| I'm off starting a new thread.
| I certainly agree with Matt and Nathan that there's no point in
| supporting C++98 separately from C++03. I also agree that new
I don't understand this part. Are you implying that there is no point
for -std=c++98 behaves differently than -std=c++03 (assuming the last
| features in future revisions of C++ should be supported only under a
| flag. I think that fixes for existing features, however, should be
| incorporated into the C++03 mode, even if they don't show up in C++03
| itself. (A "defect repot", after all, is supposed to refer to a bug
| in the standard.) I think the threshold for incorporating such fixes
| should be that the fixes are in WP status, in general, although I'd
| consider other fixes if it seems clear that the commitee is going to
| accept the change and the change seems important.
That makes a great deal of sense.
| In the particular case of PR 15049, I think we should go with Matt's
| approach. I'm not sure that, in general, I'd want to leave in support
| for what the commitee basically considers to be bugs in C++03, but in
| this case it looks very easy to do that, so we should probably go
| I think that part of the confusion here comes from the
| -pedwarn/-fpermissive situation. I think -fpermissive should just be
| removed. I think that many of our pedwarns should become errors, many
| should become warnings, -pedantic-errors should be off by default.
I'm support of -fpermissive disappearing. I would not cry if
-pedantic suddenly became inexistent (but I guess that is too much for
the moment). Indeed, most of the pedwarns should just be hard errors,
with an exceptional set being warnings. If -pedantic disappeared
then, it would be clear that -pedantic-errors should just go away too.
Gabriel Dos Reis
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112