Provided by:
manpages-dev_3.01-1_all 
NAME
signal - ANSI C signal handling
SYNOPSIS
#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
DESCRIPTION
The behavior of signal() varies across Unix versions, and has also
varied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
signal() sets the disposition of the signal signum to handler, which is
either SIG_IGN, SIG_DFL, or the address of a programmer-defined
function (a "signal handler").
If the signal signum is delivered to the process, then one of the
following happens:
* If the disposition is set to SIG_IGN, then the signal is ignored.
* If the disposition is set to SIG_DFL, then the default action
associated with the signal (see signal(7)) occurs.
* If the disposition is set to a function, then first either the
disposition is reset to SIG_DFL, or the signal is blocked (see
Portability below), and then handler is called with argument signum.
If invocation of the handler caused the signal to be blocked, then
the signal is unblocked upon return from the handler.
The signals SIGKILL and SIGSTOP cannot be caught or ignored.
RETURN VALUE
signal() returns the previous value of the signal handler, or SIG_ERR
on error.
ERRORS
EINVAL signum is invalid.
CONFORMING TO
C89, C99, POSIX.1-2001.
NOTES
The effects of signal() in a multi-threaded process are unspecified.
According to POSIX, the behavior of a process is undefined after it
ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
kill(2) or raise(3). 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.
See sigaction(2) for details on what happens when SIGCHLD is set to
SIG_IGN.
See signal(7) for a list of the async-signal-safe functions that can be
safely called inside from inside a signal handler.
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.
Portability
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 behavior.
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(3) function, one obtains
classical behavior. This is not recommended.
SEE ALSO
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2),
signalfd(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2),
bsd_signal(3), raise(3), siginterrupt(3), sigsetops(3), sigvec(3),
sysv_signal(3), feature_test_macros(7), signal(7)
COLOPHON
This page is part of release 3.01 of the Linux man-pages project. A
description of the project, and information about reporting bugs, can
be found at http://www.kernel.org/doc/man-pages/.