Re: [3.3] Followup to C++ forced unwinding

[Mark Mitchell <mark at codesourcery dot 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
approach.

> > 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 <mark@codesourcery.com>
CodeSourcery, LLC