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



NAME
       signal - ANSI C signal handling

SYNOPSIS
       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

DESCRIPTION
       The behavior of signal() varies across Unix versions, and has also var-
       ied 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  func-
       tion (a "signal handler").

       If  the signal signum is delivered to the process, then one of the fol-
       lowing 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  asso-
	  ciated with the signal (see signal(7)) occurs.

       *  If  the disposition is set to a function, then first either the dis-
	  position is reset to SIG_DFL, or the signal is blocked  (see	Porta-
	  bility  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.

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

ERRORS
       EINVAL signum is invalid.

CONFORMING TO
       C89, C99, POSIX.1-2001.

NOTES
       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
       SIG_IGN.

       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.

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

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

COLOPHON
       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 http://www.kernel.org/doc/man-pages/.



Linux				  2007-06-03			     SIGNAL(2)