| Wiki Markup |
|---|
{{setjmp}} should only be invoked from one of the contexts listed in §7.13.1.1 of \[[ISO/IEC 9899:1999|AA. References#ISO/IEC 9899-1999]\]. Invoking {{setjmp}} outside of one of these contexts results in undefined behavior (see [Undefined Behavior 119|CC. Undefined Behavior#ub_119] |
The C Standard permits setjmp to be implemented as either a macro or a function. If it is implemented as a function, it will not know enough about the calling environment to save temporary registers or dynamic stack locations. This limits the possible complexity of expressions containing setjmp. For this reason, setjmp should only be invoked from one of the following contexts:
- the entire controlling expression of a selection or iteration statement
- one operand of a relational or equality operator with the other operand an integer constant expression, with the resulting expression being the entire controlling expression of a selection or iteration statement
- the operand of a unary
!operator with the resulting expression being the entire controlling expression of a selection or iteration statement - the entire expression of an expression statement (possibly cast to void)
Invoking setjmp outside of one of these contexts results in undefined behavior (see Undefined Behavior #119
). |
After invoking longjmp, non-volatile-qualified local objects should not be accessed if their values could have changed since the invocation of setjmp. Their value in this case is considered indeterminate and accessing them is undefined behavior (see Undefined Behavior #121121, 10).
longjmp should never be used to return control to a function that has terminated execution (see Undefined Behavior #120120).
This recommendation is related to SIG32-C. Do not call longjmp() from inside a signal handler and ENV32-C. All atexit handlers must return normally.
...