[cxx-abi-dev] How to detect a forced unwind in a catch block?

[Gabriel Dos Reis]

Didn't we have a similar discussion all the way back when we were
considering whether IO cancellation  should be modeled as a "catchable" C++
exception?

On Tue, Sep 6, 2016 at 12:39 PM, Richard Smith <richardsmith at googlers.com>
wrote:

> On 6 September 2016 at 11:56, John McCall <rjmccall at apple.com> wrote:
>
>> > On Sep 6, 2016, at 11:50 AM, Thiago Macieira <thiago at kde.org> wrote:
>> > Em terça-feira, 6 de setembro de 2016, às 11:38:43 PDT, John McCall
>> escreveu:
>> >> This would be inappropriate; the appropriate solution would be to ask
>> the
>> >> committee for a new function in namespace std that could be implemented
>> >> with abi::__forced_unwind.  I believe that's the chief purpose of that
>> >> function, to allow that sort of functionality to be implemented in the
>> >> future.
>> >>
>> >> If std::current_exception works, of course, all the better.
>> >
>> > I will post to std-discussion and see if there's a consensus. I'm not
>> sure
>> > there can be because this is outside of the C++ language: there's no
>> such
>> > thing as forced unwinds in the standard.
>>
>> Hmm.  I think this used to not be true; there were library features (e.g.
>> longjmp)
>> that were allowed, but not required, to be implemented by unwinding the
>> stack.
>> But now it seems that these places have all been changed to specify
>> undefined
>> behavior if they would bypass any non-trivial destructors.
>>
>
> That's true, but it does not place restrictions on intervening 'catch
> (...)' blocks, and (since no exception has been thrown) they presumably
> must /not/ be entered. (You don't get UB from a longjmp where a
> corresponding throw would enter a catch(...) block -- although that may
> just be a wording defect.)
>
> The possibility of forced unwinding invoking a 'catch (...)' block with no
> current exception seems broken to me. For instance, this may or may not
> call terminate() if f() results in a forced unwind, depending on how
> 'throw;' is implemented:
>
>   try {
>     f();
>   } catch (...) {
>     log_error(); // might reasonably assert(std::current_exception())
>     throw;
>   }
>
> Pretending that a forced unwind throws a C++ exception of some known type
> seems likely to be the best approach -- and I'd expect that exception to be
> capturable via std::current_exception and counted by
> std::uncaught_exceptions, or exception-safe code using those facilities
> will not function correctly in the presence of a forced unwind. (And
> likewise for foreign exceptions; we presumably want to pretend that they
> are just like C++ exceptions but are of a type that doesn't match that of
> any handlers.)
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20160907/d63f1c0a/attachment.html>