Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The function signature longjmp(jmp_buf jbuf, int val) has more restricted behavior in this International Standard. A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would destroy any automatic objects.

Non-Compliant Code Example

Calling longjmp() prevents local class variables from being properly destroyed, as can be demonstrated by the following code:

...

Since the C++ standard leaves this behavior undefined, the compiler merely fails to invoke the destructor for the Counter object.

Compliant Solution

Use exceptions instead of setjmp() and longjmp(), as throwing exceptions will still invoke destructors of local class variables.

...

Code Block
Before try: Instances: 0
func(): Instances: 1
In catch: Instances: 0
After catch: Instances: 0

Exceptions

ERR34-EX1: The longjmp() function may be safely invoked if you can guarantee that no nontrivial destructors are bypassed between the longjmp() call and the corresponding setjmp().

Risk Assessment

Using setjmp() and longjmp() could lead to a denial-of-service attack due to resources not being properly destroyed.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

RES39-C

1 (low)

2 (probable)

2 (medium)

P4

L3

References

Wiki Markup
\[[ISO/IEC 14882-2003|AA. C++ References#ISO/IEC 14882-2003]\] Section 18.7
\[[Henricson 97|AA. C++ References#Henricson 97]\] Rule 13.3 Do not use {{setjmp()}} and {{longjmp()}}.

...