Created on 2021-12-15.00:00:00 last changed 1 month ago
This wording is relative to N4901.
Modify [csetjmp.syn] as indicated:
-2- The function signature longjmp(jmp_buf jbuf, int val) has more restricted behavior in this document.
A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivialdestructors for any objects with automatic storage duration. A call to setjmp or longjmp has undefined behavior if invoked in a suspension context of a coroutine ([expr.await]).
IMO the UB in [csetjmp.syn]/2 is because of the design that "every destructor call for an object shall be in effect when the lifetime of that object ends". A similar requirement is in [basic.life]/5, but it's more relaxed than the requirement for setjmp/longjmp. It seems better to harmonize the requirements in [basic.life]/5 and [csetjmp.syn]/2, which allows longjmp to skip non-trivial but no-op destructor calls. Given that Microsoft UCRT's longjmp can sometimes (but not always) call destructors, IMO we should say that it's unspecified whether longjmp calls destructor for any object whose lifetime ends.
|2021-12-18 15:46:39||admin||set||messages: + msg12255|