From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16228 invoked by alias); 23 Apr 2003 05:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 16212 invoked by uid 71); 23 Apr 2003 05:36:00 -0000 Date: Wed, 23 Apr 2003 05:36:00 -0000 Message-ID: <20030423053600.16211.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Benjamin Kosnik Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs Reply-To: Benjamin Kosnik X-SW-Source: 2003-04/txt/msg00955.txt.bz2 List-Id: The following reply was made to PR c++/10457; it has been noted by GNATS. From: Benjamin Kosnik To: Jason Merrill Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mark@codesourcery.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs Date: Wed, 23 Apr 2003 00:34:40 -0500 >You were right when you said that your testcase is ill-formed. The errors >g++ is giving are correct, per 15.4p3. I don't think so. It's not an assignment or initialization. See my updated comment, where d.foo must be called in the try block. In any case, 15.4p10, and p8 suggest that this is a runtime error, not a compile time error. I think a warning is wise, but an error I think is not conformant behavior. This blocks the explicitly granted ability of library implementors to tighten exception specs. >I suppose that, as an extension, if a derived function has a looser >exception specification we could clobber it with the one from the base >class and give a pedwarn. But that seems ugly to me. What happens is that unexpected is called, I don't see this as up for debate if we are just interpreting the standard. In this case, what unexpected does is implementation defined, and may indeed do what you are suggesting, throw bad_exception, etc. I think the current behavior is wrong. Icc seems to agree. -benjamin