SIGNAL(2) Linux Programmer's Manual SIGNAL(2)
signal - ANSI C signal handling
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
The signal() system call installs a new signal handler for the signal with number signum.
The signal handler is set to sighandler which may be a user specified function, or either
SIG_IGN or SIG_DFL.
Upon arrival of a signal with number signum the following happens. If the corresponding
handler is set to SIG_IGN, then the signal is ignored. If the handler is set to SIG_DFL,
then the default action associated to the signal (see signal(7)) occurs. Finally, if the
handler is set to a function sighandler then first either the handler is reset to SIG_DFL
or an implementation-dependent blocking of the signal is performed and next sighandler is
called with argument signum.
Using a signal handler function for a signal is called "catching the signal". The signals
SIGKILL and SIGSTOP cannot be caught or ignored.
The signal() function returns the previous value of the signal handler, or SIG_ERR on
The original Unix signal() would reset the handler to SIG_DFL, and System V (and the Linux
kernel and libc4,5) does the same. On the other hand, BSD does not reset the handler, but
blocks new instances of this signal from occurring during a call of the handler. The
glibc2 library follows the BSD behaviour.
If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal is
redefined as __bsd_signal and signal has the BSD semantics. This is not recommended.
If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or uses a
separate sysv_signal function, one obtains classical behaviour. This is not recommended.
Trying to change the semantics of this call using defines and includes is not a good idea.
It is better to avoid signal altogether, and use sigaction(2) instead.
According to POSIX, the behaviour of a process is undefined after it ignores a SIGFPE,
SIGILL, or SIGSEGV signal that was not generated by the kill(2) or the raise(3) functions.
Integer division by zero has undefined result. On some architectures it will generate a
SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.)
Ignoring this signal might lead to an endless loop.
According to POSIX (184.108.40.206) it is unspecified what happens when SIGCHLD is set to
SIG_IGN. Here the BSD and SYSV behaviours differ, causing BSD software that sets the
action for SIGCHLD to SIG_IGN to fail on Linux.
The use of sighandler_t is a GNU extension. Various versions of libc predefine this type;
libc4 and libc5 define SignalHandler, glibc defines sig_t and, when _GNU_SOURCE is
defined, also sighandler_t.
kill(1), kill(2), killpg(2), pause(2), raise(3), sigaction(2), signal(7), sigsetops(3),
Linux 2.2 2000-04-28 SIGNAL(2)