public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Benjamin Kosnik <bkoz@redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs Date: Wed, 23 Apr 2003 05:36:00 -0000 [thread overview] Message-ID: <20030423053600.16211.qmail@sources.redhat.com> (raw) 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
next reply other threads:[~2003-04-23 5:36 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-04-23 5:36 Benjamin Kosnik [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-04-23 18:46 Jason Merrill 2003-04-23 14:26 Jason Merrill 2003-04-23 4:26 Jason Merrill 2003-04-23 3:59 bkoz 2003-04-23 3:06 bkoz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030423053600.16211.qmail@sources.redhat.com \ --to=bkoz@redhat.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).