NAME

setjmp, longjmp − non-local goto

SYNOPSIS

#include <setjmp.h>

int setjmp (env)
jmp_buf env;

void longjmp (env, val)
jmp_buf env;
int val;

SYNOPSIS (4.2BSD)

int _setjmp (env)
jmp_buf env;

void _longjmp (env, val)
jmp_buf env;
int val;

DESCRIPTION

These functions are useful for dealing with errors and interrupts encountered in a low-level subroutine of a program. 

setjmp saves its stack environment in env (whose type, jmp_buf, is defined in the <setjmp.h> header file) for later use by longjmp.  It returns the value 0. 

Longjmp restores the environment saved by the last call of setjmp with the corresponding env argument.  After longjmp is completed, program execution continues as if the corresponding call of setjmp (the caller of which must not itself have returned in the interim) had just returned the value val. All accessible data had values as of the time longjmp was called. 

In the att universe, longjmp cannot cause setjmp to return the value 0.  If longjmp is invoked with a second argument of 0, setjmp will return 1.  Not so in the ucb universe.  If longjmp is invoked with a second argument of 0, setjmp will return 0. 

In the ucb universe, setjmp and longjmp save and restore the signal mask sigsetmask(2), while _setjmp and _longjmp manipulate only the C stack and registers. 

SEE ALSO

sigsetjmp(3C), signal(2), sigstack(2), sigvec(2). 

WARNING

If longjmp is called even though env was never primed by a call to setjmp, or when the last such call was in a function which has since returned, absolute chaos is guaranteed. 

setjmp does not save the current notion of whether the process is executing on the signal stack.  The result is that a longjmp to some place on the signal stack leaves the signal stack state incorrect. 

When compiled with the hc(1) C compiler, variables of automatic storage duration which are local to the function making a setjmp call may have indeterminate values when longjmp is called, if the variables are not typed volatile. 

CX/UX Programmer’s Reference Manual