This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 3652. Can we relax the preconditions of `longjmp`?

Section: 17.13.3 [csetjmp.syn] Status: NAD Submitter: Jiang An Opened: 2021-12-15 Last modified: 2022-01-30

Priority: Not Prioritized

View all issues with NAD status.

Discussion:

IMO the UB in 17.13.3 [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 6.7.3 [basic.life]/5, but it's more relaxed than the requirement for `setjmp`/`longjmp`. It seems better to harmonize the requirements in 6.7.3 [basic.life]/5 and 17.13.3 [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.

[2022-01-30 Duplicate of CWG 2361. Status changed: New → NAD.]

Proposed resolution:

This wording is relative to N4901.

1. Modify 17.13.3 [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 i If replacing the `setjmp` and `longjmp` in a `setjmp`/`longjmp` call pair by `catch` and `throw` would invoke any non-trivial destructors for any objects with automatic storage duration, it is unspecified whether the destructor is invoked for each such object. The behavior is undefined if the program depends on the side effects produced by any such unspecified destructor calls. A call to `setjmp` or `longjmp` has undefined behavior if invoked in a suspension context of a coroutine (7.6.2.4 [expr.await]).