c++/10457: exception specs vs. -fno-enforce-eh-specs

[Benjamin Kosnik]

The following reply was made to PR c++/10457; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: Jason Merrill <jason@redhat.com>
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