signal - ANSI C signal handling
void (*signal(int signum, void (*sighandler)(int)))(int);
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 function signal() 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.
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 func
tion, one obtains classical behaviour. This is not recom
Trying to change the semantics of this call using defines
and includes is not a good idea. It is better to avoid
If you're confused by the prototype at the top of this
manpage, it may help to see it separated out thus:
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
(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.)
According to POSIX, the behaviour of a process is unde
fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
that was not generated by the kill() or the raise() func
tions. 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 gener
ate SIGFPE.) Ignoring this signal might lead to an end
According to POSIX (B.18.104.22.168) you must not set the action
for SIGCHLD 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.
kill(1), kill(2), killpg(2), pause(2), raise(3), sigac
tion(2), signal(7), sigsetops(3), sigvec(2), alarm(2)