Setjmp.h

setjmp.h is a header defined in the C standard library to provide "non-local jumps": control flow that deviates from the usual subroutine call and return sequence. The complementary functions setjmp and longjmp provide this functionality.

A typical use of setjmp/longjmp is implementation of an exception mechanism that exploits the ability of longjmp to reestablish program or thread state, even across multiple levels of function calls. A less common use of setjmp is to create syntax similar to coroutines.

Member functions

intsetjmp(jmp_bufenv)

Sets up the local jmp_buf buffer and initializes it for the jump. This routine [1] saves the program's calling environment in the environment buffer specified by the env argument for later use by longjmp. If the return is from a direct invocation, setjmp returns 0. If the return is from a call to longjmp, setjmp returns a nonzero value.

voidlongjmp(jmp_bufenv,intvalue)

Restores the context of the environment buffer env that was saved by invocation of the setjmp routine [1] in the same invocation of the program. Invoking longjmp from a nested signal handler is undefined. The value specified by value is passed from longjmp to setjmp. After longjmp is completed, program execution continues as if the corresponding invocation of setjmp had just returned. If the value passed to longjmp is 0, setjmp will behave as if it had returned 1; otherwise, it will behave as if it had returned value.

setjmp saves the current environment (the program state), at some point of program execution, into a platform-specific data structure (jmp_buf) that can be used at some later point of program execution by longjmp to restore the program state to that saved by setjmp into jmp_buf. This process can be imagined to be a "jump" back to the point of program execution where setjmp saved the environment. The (apparent) return value from setjmp indicates whether control reached that point normally (zero) or from a call to longjmp (nonzero). This leads to a common idiom: if(setjmp(x)){/* handle longjmp(x) */}.

POSIX.1 does not specify whether setjmp and longjmp save and restore the current set of blocked signals; if a program employs signal handling it should use POSIX's sigsetjmp/siglongjmp.

Member types

jmp_buf

An array type, such as struct __jmp_buf_tag[1], [2] suitable for holding the information needed to restore a calling environment.

The C99 Rationale describes jmp_buf as being an array type for backward compatibility; existing code refers to jmp_buf storage locations by name (without the & address-of operator), which is only possible for array types. ^[3]

Caveats and limitations

When a "non-local goto" is executed via setjmp/longjmp in C++, normal "stack unwinding" does not occur. Therefore, any required cleanup actions will not occur either. This could include closing file descriptors, flushing buffers, or freeing heap-allocated memory.

If the function in which setjmp was called returns, it is no longer possible to safely use longjmp with the corresponding jmp_buf object. This is because the stack frame is invalidated when the function returns. Calling longjmp restores the stack pointer, which—because the function returned—would point to a non-existent and potentially overwritten or corrupted stack frame. ^{[4] [5]}

Similarly, C99 does not require that longjmp preserve the current stack frame. This means that jumping into a function which was exited via a call to longjmp is undefined. ^[6]

Example usage

Simple example

The example below shows the basic idea of setjmp. There, main() calls first(), which in turn calls second(). Then, second() jumps back into main(), skipping first()'s call of printf().

#include<stdio.h>#include<setjmp.h>staticjmp_bufbuf;voidsecond(){printf("second\n");// printslongjmp(buf,1);// jumps back to where setjmp was called - making setjmp now return 1}voidfirst(){second();printf("first\n");// does not print}intmain(){if(!setjmp(buf))first();// when executed, setjmp returned 0else// when longjmp jumps back, setjmp returns 1printf("main\n");// printsreturn0;}

When executed, the above program will output:

second main 

Notice that although the first() subroutine gets called, "first" is never printed. "main" gets printed as the conditional statement if (!setjmp(buf)) is executed a second time.

Exception handling

In this example, setjmp is used to bracket exception handling, like try in some other languages. The call to longjmp is analogous to a throw statement, allowing an exception to return an error status directly to the setjmp. The following code adheres to the 1999 ISO C standard and Single UNIX Specification by invoking setjmp in a limited range of contexts: ^[7]

• As the condition to an if, switch or iteration statement
• As above in conjunction with a single ! or comparison with an integer constant
• As a statement (with the return value unused)

Following these rules can make it easier for the implementation to create the environment buffer, which can be a sensitive operation. ^[3] More general use of setjmp can cause undefined behaviour, such as corruption of local variables; conforming compilers and environments are not required to protect or even warn against such usage. However, slightly more sophisticated idioms such as switch ((exception_type = setjmp(env))) { } are common in literature and practice, and remain relatively portable. A simple conforming methodology is presented below, where an additional variable is maintained along with the state buffer. This variable could be elaborated into a structure incorporating the buffer itself.

In a more modern-looking example, the usual "try" block would be implemented as a setjmp (with some preparation code for multilevel jumps, as seen in first), the "throw" as longjmp with the optional parameter as the exception, and the "catch" as the "else" block under "try".

#include<setjmp.h>#include<stdio.h>#include<stdlib.h>#include<string.h>staticvoidfirst();staticvoidsecond();/* Use a file scoped static variable for the exception stack so we can access * it anywhere within this translation unit. */staticjmp_bufexception_env;staticintexception_type;intmain(void){char*volatilemem_buffer=NULL;if(setjmp(exception_env)){// if we get here there was an exceptionprintf("first failed, exception type: %d\n",exception_type);}else{// Run code that may signal failure via longjmp.puts("calling first");first();mem_buffer=malloc(300);// allocate a resourceprintf("%s\n",strcpy(mem_buffer,"first succeeded"));// not reached}free(mem_buffer);// NULL can be passed to free, no operation is performedreturn0;}staticvoidfirst(){jmp_bufmy_env;puts("entering first");// reachedmemcpy(my_env,exception_env,sizeofmy_env);switch(setjmp(exception_env)){case3:// if we get here there was an exception.puts("second failed, exception type: 3; remapping to type 1");exception_type=1;default:// fall throughmemcpy(exception_env,my_env,sizeofexception_env);// restore exception stacklongjmp(exception_env,exception_type);// continue handling the exceptioncase0:// normal, desired operationputs("calling second");// reached second();puts("second succeeded");// not reached}memcpy(exception_env,my_env,sizeofexception_env);// restore exception stackputs("leaving first");// never reached}staticvoidsecond(){puts("entering second");// reachedexception_type=3;longjmp(exception_env,exception_type);// declare that the program has failedputs("leaving second");// not reached}

This program's output is:

calling first entering first calling second entering second second failed, exception type: 3; remapping to type 1 first failed, exception type: 1 

Cooperative multitasking

C99 provides that longjmp is guaranteed to work only when the destination is a calling function, i.e., that the destination scope is guaranteed to be intact. Jumping to a function that has already terminated by return or longjmp is undefined. ^[6] However, most implementations of longjmp do not specifically destroy local variables when performing the jump. Since the context survives until its local variables are erased, it could actually be restored by setjmp. In many environments (such as Really Simple Threads and TinyTimbers), idioms such as if(!setjmp(child_env)) longjmp(caller_env); can allow a called function to effectively pause-and-resume at a setjmp.

This is exploited by thread libraries to provide cooperative multitasking facilities without using setcontext or other fiber facilities.

Considering that setjmp to a child function will generally work unless sabotaged, and setcontext, as part of POSIX, is not required to be provided by C implementations, this mechanism may be portable where the setcontext alternative fails.

Since no exception will be generated upon overflow of one of the multiple stacks in such a mechanism, it is essential to overestimate the space required for each context, including the one containing main() and including space for any signal handlers that might interrupt regular execution. Exceeding the allocated space will corrupt the other contexts, usually with the outermost functions first. Unfortunately, systems requiring this kind of programming strategy are often also small ones with limited resources.

#include<setjmp.h>#include<stdio.h>jmp_bufmainTask,childTask;voidcall_with_cushion();voidchild();intmain(){if(!setjmp(mainTask)){call_with_cushion();// child never returns, yield}// execution resumes after this "}" after first time that child yieldswhile(1){printf("Parent\n");if(!setjmp(mainTask))longjmp(childTask,1);// yield - note that this is undefined under C99}}voidcall_with_cushion(){charspace[1000];// Reserve enough space for main to runspace[999]=1;// Do not optimize array out of existencechild();}voidchild(){while(1){printf("Child loop begin\n");if(!setjmp(childTask))longjmp(mainTask,1);// yield - invalidates childTask in C99printf("Child loop end\n");if(!setjmp(childTask))longjmp(mainTask,1);// yield - invalidates childTask in C99}/* Don't return. Instead we should set a flag to indicate that main()       should stop yielding to us and then longjmp(mainTask, 1) */}

References

1. ISO C states that setjmp must be implemented as a macro, but POSIX explicitly states that it is undefined whether setjmp is a macro or a function.
2. This is the type used by the GNU C Library, version 2.7
3. C99 Rationale, version 5.10, April 2003, section 7.13
4. CS360 Lecture Notes — Setjmp and Longjmp
5. setjmp(3) Archived 2009-07-26 at the Wayback Machine
6. ISO/IEC 9899:1999, 2005, 7.13.2.1:2 and footnote 211
7. setjmp : set jump point for a non-local goto – System Interfaces Reference, The Single UNIX Specification , Version 4 from The Open Group

Further reading

• Nidito, Francesco (July 2, 2016). "Exceptions in C with Longjmp and Setjmp". Groups.Di.Unipi.it. Retrieved 2024-01-02.

External links

• Computer programming portal

• setjmp : set jump point for a non-local goto – System Interfaces Reference, The Single UNIX Specification , Version 4 from The Open Group
• is there sigsetjmp/siglongjmp (again) (about this functions in mingw/MSYS)