signal - ANSI C signal handling


       #include <signal.h>

       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­
       less loop.

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


       ANSI C


       kill(1), kill(2), killpg(2),  pause(2),  raise(3),  sigac­
       tion(2), signal(7), sigsetops(3), sigvec(2), alarm(2)