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 the signal is blocked and
sighandler is called with argument signum. The signal remains blocked
during the execution of the signal handler.
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 error.
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.
In a libc5 system including <bsd/signal.h> instead of <signal.h> makes
signal to be redefined as __bsd_signal and signal has the BSD semantics.
This is not recommended.
In a glibc2 system defining a feature test macro such as _XOPEN_SOURCE
or using a separate sysv_signal function, the classical behaviour is
obtained. 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
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 (220.127.116.11) 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 the 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), sig-
nal(7), sigsetops(3), sigvec(2), alarm(2)
Linux 2.2 2000-04-28 SIGNAL(2)
[ Back ]