This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [rfc] fix libstdc++/10606
- From: Richard Henderson <rth at redhat dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: Paolo Carlini <pcarlini at suse dot de>, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, Cary Coutant <cary at cup dot hp dot com>, Martin Sebor <sebor at roguewave dot com>
- Date: Tue, 4 Jan 2005 14:47:21 -0800
- Subject: Re: [rfc] fix libstdc++/10606
- References: <20041228082031.GA6135@redhat.com> <41D1D97E.4070506@suse.de> <20041228225439.GA7588@redhat.com> <20050104155218.1e3c1cb8.bkoz@redhat.com>
On Tue, Jan 04, 2005 at 03:52:18PM -0600, Benjamin Kosnik wrote:
> + {
> + S s0;
> + throw s0; // s1 is the exception object
>
> we want
>
> + { 1, 0, false },
>
> for the s1 temporary object test data. I think this is correct because
> this test occurs in the temporary object's ctor body, before the the
> object is considered complete. I don't think it makes sense to have
> uncaught_exception return true here, since the "uncaught exception
> object" in question hasn't yet been (fully) constructed.
On the other hand, we *will* std::terminate if the s0->s1 copy
constructor throws -- just like if the s1->s2 copy constructor
throws while setting up the catch handler.
Given that the copy constructor cannot throw, I think it makes
sense to consider that we've begun processing the exception,
and thus there must be an uncaught exception.
It all depends on what you consider uncaught_exception useful
for, I guess.
r~