catch(...) and forced unwind

[Jamie Lokier]

Mark Mitchell wrote:
> You'd also want to do the disabling inside "throw (int)" functions for
> example.  And, then, you'd want to reenable if a "throw (int)" function
> called a "throw (...)" function (perhaps inside a try-block).
> 
> I think that if you did all that, your idea would not violate either
> standard.  However, it still wouldn't really solve the problem.  For
> example:
> 
>   // This function has no exception-specification but I know
>   // it only throws ints!
>   inline void f() { printf ("Throwing now!"); throw 3; }
> 
>   // This function will never throw anything.
>   void g() throw () { try { f(); } catch (int) { } }
> 
> is the sort of C++ code that could be validated in a non-threaded
> environment, but would call "std::terminate" if "printf" were
> cancelled.

No, it wouldn't call std::terminate.

g() would disable cancellations for its duration due to "throw()", and
the "try {} catch (int) {}" block doesn't change that.  ("catch (...)"
would change it as you said).  g() calls f() which makes no change to
the cancellation state.  Therefore the printf cannot be cancelled -
the cancellation will be deferred to the next cancellation point after
g() returns, assuming g()'s caller didn't disable cancellations too.

-- Jamie