Understanding setjmp/longjmp

For a long time, I have been aware of the existence of the standard C functions setjmp and longjmp and that they can be used to simulate exceptions in C code. However, it wasn't until yesterday that I had to use them... and it was not trivial. The documentation for these functions tends to be confusing, and understanding them required looking for additional documents and a bit of experimentation. Let's see if this post helps in clarifying how these functions work.

The first call to setjmp causes the process state (stack, CPU registers, etc.) to be saved in the provided jmp_buf structure and, then, a value of 0 to be returned. A subsequent call to longjmp with the same jmp_buf structure causes the process to go "back in time" to the state stored in said structure. The way this is useful is that, when going back in time, we tweak the return value of the setjmp call so we can actually run a second (or third or more) path as if nothing had happened.

Let's see an example:

#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>

static jmp_buf buf;

static void
myfunc(void)
{
   printf("In the function.n");

   ... do some complex stuff ...

   /* Go back in time: restore the execution context of setjmp
    * but make the call return 1 instead of 0. */
   longjmp(buf, 1);

   printf("Not reached.n");
}

int
main(void) {
   if (setjmp(buf) == 0) {
       /* Try block. */
       printf("Trying some function that may throw.n");
       myfunc();
       printf("Not reached.n");
   } else {
       /* Catch block. */
       printf("Exception caught.n");
   }
   return EXIT_SUCCESS;
}

The example above shows the following when executed:

Trying some function that may throw.
In the function.
Exception caught.

So, what happened above? The code starts by calling setjmp to record the execution state and the call returns 0, which causes the first part of the conditional to run. You can think of this clause as the "try" part of an exception-based code. At some point during the execution of myfunc, an error is detected and is "thrown" by a call to longjmp and a value of 1. This causes the process to go back to the execution of setjmp but this time the call returns 1, which causes the second part of the conditional to run. You can think of this second clause as the "catch" part of an exception-based code.

It is still unclear to me what the "execution context" stored in jmp_buf is: the documentation does not explain what kind of resources are correctly unwinded when the call to longjmp is made... which makes me wary of using this technique for exception-like handling purposes. Oh, and this is even less clear in the context of C++ code and, e.g. calls to destructors. Would be nice to expand the description of these APIs in the manual pages.

Featured software

Featured posts