signal - ANSI C signal handling
SYNOPSIS
#include <signal.h>
void (*signal(int signum, void (*sighandler)(int)))(int);
DESCRIPTION
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.
RETURN VALUE
The function signal() returns the previous value of the
signal handler, or SIG_ERR on error.
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 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
mended.
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.
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
less loop.
According to POSIX (3.3.1.3) it is unspecified what hap
pens 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.
CONFORMING TO
ANSI C
SEE ALSO
kill(1), kill(2), killpg(2), pause(2), raise(3), sigac
tion(2), signal(7), sigsetops(3), sigvec(2), alarm(2)
Man(1) output converted with
man2html