setjmp(3C)setjmp(3C)NAMEsetjmp(), longjmp(), sigsetjmp(), siglongjmp() - non-local goto
and are useful for dealing with errors and interrupts encountered in a
low-level subroutine of a program. They exist in three variant forms:
and and and Unless indicated otherwise, references to and apply to all
saves its stack environment in
env (whose type, is defined in the header
file) for later use by It returns the value
restores the environment saved by the last call of
with the corresponding env argument. After is
completed, program execution continues as if
the corresponding call of (which must not
itself have returned in the interim) had just
returned the value val. cannot cause to
return the value If is invoked with a second
argument of returns All accessible data values
are valid as of the time is called.
Upon the return from a call caused by a the values of any non-static or
non-volatile local variables belonging to the routine from which was
called are undefined. Code which depends on such values is not guaran‐
teed to be portable.
The following functions behave the same as and except in the handling
of the process' signal mask (see sigaction(2)). This distinction is
only significant for programs which use and/or
These always save and restore the signal mask.
These never manipulate the signal
Saves the signal mask of the calling
thread if and only if
savemask is non-
Restores the signal mask if and only
if it is saved by
If a is executed and the environment in
which the is executed no longer exists,
errors can occur. The conditions under
which the environment of the no longer
exists include exiting the procedure that
contains the call, and exiting an inner
block with temporary storage (such as a
block with declarations in C or a statement
in Pascal). This condition might not be
detectable, in which case the occurs and,
if the environment no longer exists, the
contents of the temporary storage of an
inner block are unpredictable. This condi‐
tion might also cause unexpected process
termination. If the procedure has been
exited the results are unpredictable.
Passing a pointer to a buffer not created
by passing a pointer to a buffer not cre‐
ated by either or passing a pointer to a
buffer not created by or passing any of
these three functions a buffer that has
been modified by the user, can cause all
the problems listed above, and more.
Some implementations of Pascal support a
``try/recover'' mechanism, which also cre‐
ates stack marker information. If a opera‐
tion occurs in a scope which is nested
inside a try/recover, and the corresponding
is not inside the scope of the try/recover,
the recover block will not be executed and
the currently active recover block will
become the one enclosing the if one exists.
A call to to leave the guaranteed stack
space reserved by might remove the guaran‐
tee that the ordinary execution of the pro‐
gram will not extend into the guaranteed
space. It might also cause the program to
forever lose its ability to automatically
increase the stack size, and the program
might then be limited to the guaranteed
The result of using within an expression
can be unpredictable.
If is called even though env was never
primed by a call to or when the last such
call was in a function that has since
returned, total chaos is guaranteed.
The effect of a call to where the initial‐
ization of the argument was not performed
in the calling thread is undefined. The
effect of a call to where the initializa‐
tion of the argument was not performed in
the calling thread is undefined.
The contents of the buffer are architecture
and compilation environment specific.
Thus, objects built using these functions
may not be supported across architectures.
was developed by AT&T and HP.
SEE ALSOsigaction(2), sigblock(2), signal(5), sig‐
procmask(2), sigsetmask(2), sigspace(2),