[cxx-abi-dev] A question about terminate handlers

[Marshall Clow]

On Feb 18, 2014, at 8:49 AM, John McCall <rjmccall at apple.com> wrote:

> On Feb 18, 2014, at 8:02 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>> On Feb 17, 2014, at 10:50 AM, John McCall <rjmccall at apple.com> wrote:
>>> On Feb 15, 2014, at 11:05 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>>>> Specifically:
>>>> 	libc++ & libc++abi call the terminate handler that was active when the exception was created.
>>>> 	libstdc++ and libsup++ call the terminate handler that was installed when the exception was rethrown.
>>>> 
>>>> Does the C++ ABI document have anything to say about terminate handlers being updated while an exception is in flight?
>>> 
>>> I would expect this to be controlled by the language standard, not by the ABI document.
>> 
>> And yet it is spelled out in the ABI document in section 2.2.2.1: (http://mentorembedded.github.io/cxx-abi/abi-eh.html)
>> 
>> 	• The fields unexpectedHandler and terminateHandler contain pointers to the unexpected and terminate handlers at the point where the exception is thrown. The ISO C++ Final Draft International Standard [lib.unexpected] (18.6.2.4) states that the handlers to be used are those active immediately after evaluating the throw argument. If destructors change the active handlers during unwinding, the new values are not used until unwinding is complete.
> 
> To me, everything after the first sentence here is (1) explanatory and (2) deferring to the standard.
> 
>>> Amusingly, the current standard is simply ungrammatical:
>>>  N3797 [terminate]p1:
>>>    Called by the implementation when exception handling must be abandoned
>>>    for any of several reasons, in effect immediately after throwing the exception.
>>> Clearly what’s “in effect” is supposed to be the terminate_handler, but...
>>> 
>>> As far as I can tell, this is a splice left over from a previous revision.  e.g.
>>>  C++03 [lib.terminate]p1:
>>>    Effect: Calls the terminate_handler function in effect immediately after evaluating
>>>    the throw-expression, if called by the implementation, or calls the current
>>>    terminate_handler function, if called by the program.
>>> 
>>> Both standards are vague about *which* throw-expression is meant when more
>>> than one is associated with the same exception object.  If you can get the
>>> committee to clarify, please ask them to consider what should happen with
>>> std::rethrow_exception as well.
>> 
>> This is LWG issue 2088: http://cplusplus.github.io/LWG/lwg-active.html#2088
>> Apparently this was changed right before C++11 was released (see N3242 for the actual change), and it is (as you say) confused.
>> The editor’s comments in n3242 reflect this confusion.
>> 
>> So, what we have is that C++98/03 specifies things one way, and C++11/14 (arguably) a different way.
>> And libc++abi implements the C++03 standard, and libsup++ (4.8) implements the C++11 standard.
> 
> If the standard is now being changed to always use the current terminate_handler at the time that the terminate is triggered, then neither library is implementing it correctly, and in fact these fields in the exception info are now obsolete.  That’s an explicit change in specified behavior, though, so I’m a little surprised by it.
> 
> The difference as you’ve described it is just that libsupc++ is overwriting the handler fields on a rethrow (“throw;”), and libc++abi is not.  CI 2088 actually doesn’t identify this as an ambiguity, but it seems to me to be the only truly unaddressed problem unless they’re really switching the semantics to always use the current handler.

That is exactly the difference that I am describing.

And I’d like to see that difference removed (and I don’t really care which way it is resolved).
I also agree that it should be decided by the C++ standards group, not the members of this mailing list.

But I think that people here should be aware of it.

— Marshall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140218/644278ea/attachment-0001.html>