Unclear description of longjmp undefined behavior
17.13.3 [csetjmp.syn]
Zhihao Yuan

Created on 2017-10-20.00:00:00 last changed 2 weeks ago


Date: 2022-01-06.00:00:00

Additional note, January, 2022:

See also library issue 3652.

Date: 2018-10-15.00:00:00

Notes from the October, 2018 teleconference:

There are a number of unanswered questions in the current wording, including the impact on the current exception (whether it still exists) after a longjmp out of a handler, the impact on the initialization locks if jumping from the initialization of a local static data member, etc. One thought was to restrict use of longjmp to “plain C functions”. Another was to say if the program would have different behavior via the use of exceptions the behavior is undefined. There was no consensus on how to proceed.

Date: 2017-10-20.00:00:00

According to 17.13.3 [csetjmp.syn] paragraph 2,

A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any automatic objects.

The intent is clear, that transferring control from point A to point B via longjmp has undefined behavior if throwing an exception at point A and catching it at point B would invoke non-trivial destructors. The wording could be more precise.

See also the corresponding editorial issue for additional discussion.

Date User Action Args
2022-01-06 00:00:00adminsetmessages: + msg6620
2020-12-15 00:00:00adminsetmessages: + msg6286
2017-10-20 00:00:00admincreate