Provided by: manpages-dev_2.77-1_all bug


       signal - ANSI C signal handling


       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);


       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.


       signal()  returns  the previous value of the signal handler, or SIG_ERR
       on error.


       EINVAL signum is invalid.


       C89, C99, POSIX.1-2001.


       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

       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.

       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.


       kill(1),   alarm(2),   kill(2),   killpg(2),   pause(2),  sigaction(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)


       This page is part of release 2.77 of the Linux  man-pages  project.   A
       description  of  the project, and information about reporting bugs, can
       be found at