Provided by: manpages-dev_2.17-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  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 with 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 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
       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  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.


       The effects of this call in a multi-threaded process are unspecified.

       The  routine  handler  must be very careful, since processing elsewhere
       was interrupted at some arbitrary point. POSIX has the concept of "safe
       function".   If  a  signal  interrupts  an unsafe function, and handler
       calls  an  unsafe  function,  then  the  behavior  is  undefined.  Safe
       functions  are  listed  explicitly in the various standards.  The POSIX
       1003.1-2003 list is

       _Exit() _exit()  abort()  accept()  access()  aio_error()  aio_return()
       aio_suspend()  alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed()
       cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect()
       creat()  dup()  dup2()  execle()  execve()  fchmod()  fchown()  fcntl()
       fdatasync() fork() fpathconf() fstat()  fsync()  ftruncate()  getegid()
       geteuid()   getgid()   getgroups()   getpeername()  getpgrp()  getpid()
       getppid() getsockname() getsockopt() getuid()  kill()  link()  listen()
       lseek()  lstat()  mkdir()  mkfifo()  open()  pathconf()  pause() pipe()
       poll() posix_trace_event() pselect() raise() read()  readlink()  recv()
       recvfrom()   recvmsg()  rename()  rmdir()  select()  sem_post()  send()
       sendmsg() sendto() setgid() setpgid()  setsid()  setsockopt()  setuid()
       shutdown()    sigaction()    sigaddset()    sigdelset()   sigemptyset()
       sigfillset()    sigismember()    signal()    sigpause()    sigpending()
       sigprocmask()   sigqueue()   sigset()   sigsuspend()  sleep()  socket()
       socketpair() stat() symlink() sysconf()  tcdrain()  tcflow()  tcflush()
       tcgetattr()  tcgetpgrp()  tcsendbreak()  tcsetattr() tcsetpgrp() time()
       timer_getoverrun()  timer_gettime()  timer_settime()  times()   umask()
       uname() unlink() utime() wait() waitpid() write().

       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
       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

       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),  alarm(2),  kill(2),  pause(2),  sigaction(2),  sigpending(2),
       sigprocmask(2),  sigqueue(2),   sigsuspend(2),   killpg(3),   raise(3),
       sigsetops(3), sigvec(3), signal(7)