The setjmp() macro should be invoked from only one of the contexts listed in Section 7.13.1.1 of the C Standard [ISO/IEC 9899:2011]. Invoking setjmp() outside of one of these contexts results in undefined behavior. (See undefined behavior 125.)
After invoking longjmp(), non–volatilenon-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 behaviors 127 and 10.)
The longjmp() function should never be used to return control to a function that has terminated execution. (See undefined behavior 126.)
...
Because g() has finished executing at the time longjmp() is called, it is no longer on the stack. When do_stuff() is invoked, its stackframe stack frame occupies the same memory as the old stackframe stack frame of g(). In this case, a was located in the same location as the return address of function g(). The call to memcpy() overwrites the return address, so when longjmp() sends control back to function g(), the function returns to the wrong address (in this case, to function bad()).
...
In this noncompliant example, non–volatilenon-volatile-qualified objects local to the function that invoked the corresponding setjmp() have indeterminate values after longjmp() is executed if their value has been changed since the invocation of setjmp().
...
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MSC22-C | low | probable | medium | P4 | L3 |
Related Guidelines
ISO/IEC 9899:2011 Section 7.13, "Nonlocal jumps <setjmp.h>," Annex J, "Portability issues"
...
...