This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] unexpected/terminate support for MS CRT
AbandonedPublic

Authored by K-ballo on Aug 29 2014, 2:48 PM.

Details

Summary

MS CRT provides implementation of those handler functions, defer to them.

Diff Detail

Event Timeline

K-ballo updated this revision to Diff 13111.Aug 29 2014, 2:48 PM
K-ballo retitled this revision from to unexpected/terminate support for MS CRT.
K-ballo updated this object.
K-ballo edited the test plan for this revision. (Show Details)
K-ballo added reviewers: mclow.lists, EricWF.
K-ballo added a subscriber: Unknown Object (MLST).
K-ballo added inline comments.Aug 29 2014, 2:51 PM
test/depr/exception.unexpected/set.unexpected/get_unexpected.pass.cpp
32

This assertion does not hold for MSVCRT, as a null handler represents the default behavior. Would it be better to make this check conditionally instead of marking the whole test as failed?

40

This does not hold for MSVCRT either. Assuming the previous assertion is skipped for it, this could be tested by setting the unexpected handler to its original value and calling unexpected().

K-ballo retitled this revision from unexpected/terminate support for MS CRT to [libcxx] unexpected/terminate support for MS CRT.Aug 29 2014, 4:32 PM
mclow.lists accepted this revision.EditedFeb 17 2015, 8:34 AM
mclow.lists edited edge metadata.

This looks OK to me.
Ugly, but OK.

test/depr/exception.unexpected/set.unexpected/get_unexpected.pass.cpp
32

I believe that this check is incorrect.
Section D.8.3 says of get_unexpected:
Returns: The current unexpected_handler. [ Note: This may be a null pointer value. — end note ]

40

Yes, I think that's better.

This revision is now accepted and ready to land.Feb 17 2015, 8:34 AM

Waiting for VS2015RTM

You will also need to change the test:

test/depr/exception.unexpected/set.unexpected/set_unexpected.pass.cpp

as it makes similar assumptions about an initial non-null handler.

K-ballo abandoned this revision.Oct 12 2017, 4:11 PM