Previous | Table of Contents | Next |
The header <signal.h> declares two functions for dealing with asynchronous interrupts or signals. There are several possible signals, identified by integer constants, for which this header defines symbolic names:
SIGABRT | The signal generated by the abort function. |
SIGFPE | A signal generated by math errors, such as divide by 0. (The spelling FPE is historical, and once stood for floating-point exception, although the signal can occur for integer exceptions as well.) |
SIGILL | A signal generated due to attempts to execute illegal instructions. |
SIGINT | A signal generated by a keyboard interrupt (e.g., control-C). |
SIGSEGV | A signal generated by memory access violations (segmentation violations). |
SIGTERM | A signal generated when the process is terminated by some external agent. |
Many implementations define additional signal values.
3.10.7.1. signal
void (*signal(int sig, void (*func)(int)))(int)
The signal function is used to specify the action that should be taken when a signal is received. By default, all signals terminate the program, but by calling signal, the program can arrange to ignore the signal, or to have it handled by transferring control to a specified function.
sig is the signal to be handled, that is, one of the SIGxxx constants. func is either the manifest constant SIG_IGN (which requests that the signal be ignored), the constant SIG_DFL (which requests that the default handling be restored), or a pointer to a user-supplied function that is to be called when the function is received. The function should be a void function accepting one int parameter and will be called with the signal number as that parameter.
If func is a function to be called, it is implementation defined whether further instances of signal sig are somehow blocked while the function is executing, or whether the equivalent of signal(sig, SIG_DFL) is performed (that is, resetting the signal to its default action) before the function begins executing.
The signal function returns the previous disposition of the signal, whether SIG_DFL, SIG_IGN, or a function pointer. signals declaration is therefore complex: It is a function returning a pointer to a function (a function that takes one int parameter and returns void), and its second argument is also a pointer to a function (again, one that takes one int parameter and returns void).
For example, here is a code fragment which arranges that a function exithandler be called if the interrupt signal is received, but only if that signal was not already being ignored:
extern void exithandler(int); if(signal(SIGINT, SIG_IGN) != SIG_IGN) signal(SIGINT, exithandler);
3.10.7.2. raise
int raise(int sig)
The raise function sends the specified signal to the current program.
The functions declared in the header <setjmp.h> allow a program to perform nonlocal jumps, achieving the approximate result of a goto between functions.
Nonlocal jumps do not use static labels, as gotos do; instead, the program calls a function (setjmp) at a point which it wishes to be able to jump to later. The context at this point is stashed away in an object of type jmp_buf. jmp_buf is an opaque type, although for historical reasons it is constrained to be an array type. Because a later jump to this saved spot is performed by unwinding the function call stack, these jumps must always be initiated somewhere in the calling hierarchy at or beneath the function that called setjmp.
3.10.8.1. setjmp
int setjmp(jmp_buf context)
setjmp saves the programs current location in the supplied context object and returns 0. Later, if longjmp is called with the same context object, it will appear that setjmp had returned with a nonzero value.
3.10.8.2. longjmp
void longjmp(jmp_buf context, int retval)
longjmp causes an immediate jump back to a context previously saved by setjmp. The jump is performed by unwinding the function-call stack, so the function that called setjmp must still be active (that is, the function calling longjmp must generally be a descendant of the function that called setjmp).
As the long jump completes, it will appear to the jumped-to function as if its prior call to setjmp has returned again, this time with the value retval. That function should not rely on any of its other variables, however, as it is difficult to say whether they will have their values as of the initial call to setjmp or as of the call to the function that eventually called longjmp.
Previous | Table of Contents | Next |