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

### 619. Longjmp wording problem

Section: 17.14 [support.runtime] Status: CD1 Submitter: Lawrence Crowl Opened: 2007-01-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [support.runtime].

View all issues with CD1 status.

Discussion:

The wording for `longjmp` is confusing.

17.14 [support.runtime] -4- Other runtime support

> The function signature `longjmp(jmp_buf jbuf, int val)` has more restricted behavior in this International Standard. If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to `longjmp(jbuf, val)` that the throw point that transfers control to the same (destination) point has undefined behavior.

Someone at Google thinks that should say "then a call to `longjmp(jbuf, val)` *at* the throw point that transfers control".

Bill Gibbons thinks it should say something like "If any automatic objects would be destroyed by an exception thrown at the point of the longjmp and caught only at the point of the setjmp, the behavior is undefined."

Proposed resolution:

In general, accept Bill Gibbons' recommendation, but add "call" to indicate that the undefined behavior comes from the dynamic call, not from its presence in the code. In 17.14 [support.runtime] paragraph 4, change

> The function signature `longjmp(jmp_buf jbuf, int val)` has more restricted behavior in this International Standard. If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to `longjmp(jbuf, val)` that the throw point that transfers control to the same (destination) point has undefined behavior. A `setjmp`/`longjmp` call pair has undefined behavior if replacing the `setjmp` and `longjmp` by `catch` and `throw` would destroy any automatic objects.