This is the mail archive of the
mailing list for the GCC project.
Re: [3.3] Followup to C++ forced unwinding
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, ncm at cantrip dot org
- Date: 30 Apr 2003 17:57:58 -0700
- Subject: Re: [3.3] Followup to C++ forced unwinding
- Organization: CodeSourcery, LLC
- References: <20030430175335.GA18958@twiddle.net> <email@example.com> <20030430210342.GB697@redhat.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <3EB06CCE.email@example.com>
On Wed, 2003-04-30 at 17:39, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Mark Mitchell wrote:
> > This whole idea -- that we unwind the stack running code when a thread
> > is cancelled -- is outside POSIX.
> You miss the point. Doing something outside POSIX is one thing.
> Requesting something which isn't possible is the other. It's not just
> not defined behavior that cancellations cannot be interrupted, it's
> impossible in the implementations. That's the point. Bogus
> requirements from the C++ integration cannot overwrite restrictions the
> implementations have.
You've not explained how falling off the end of a catch handler is
impossible, but running a destructor that doesn't return, is possible.
> > I'm not sure why this would be a bug -- it's not even undefined
> > behavior. But, if it is a bug, then a "catch(...)" that doesn't rethrow
> > would be the same bug. There's no harm in providing the user a
> > C++-specific way to make the same mistake.
> You have the same problem as Nathan.
> In C a programmers has to explicitly add code to violate the rules and
> it is a burden.
> If rethrows are not done automatically the ommission of one piece of
> code which is not required leads to desaster.
Skipping over a "catch(...)" block is a bad idea.
Inserting an implicit rethrow is a bad idea.
A compromise position is to call std::terminate for now. At some later
date, when a consensus has arisen, after consulting the POSIX and C++
committees, we can choose what to do. In the meantime, programmers will
be incentivized to convert to the less-controversial destructor-based
> > There's nothing that says that a destructor must return, or cannot
> > contain arbitrary code.
> Of course they cannot contain arbitrary code. You're not allowed to
> call longjmp(9 etc in destructors.
You're nitpicking; you know what I meant.
(And besides, you can call longjmp. There are restrictions on where the
corresponding setjmp can be.)
Mark Mitchell <firstname.lastname@example.org>