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.13 [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.13 [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.13 [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.