SIGNAL(2)                  Linux Programmer's Manual                 SIGNAL(2)

       signal - ANSI C signal handling

       #include <signal.h>

       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  han-
       dler  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 error.

       The original Unix signal() would reset the handler to SIG_DFL, and Sys-
       tem  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 seman-
       tics. 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 sig-
       nal.  (Also dividing the most  negative  integer  by  -1  may  generate
       SIGFPE.)  Ignoring this signal might lead to an endless loop.

       According  to  POSIX  (  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.

       ANSI C

       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)