signal - ANSI C signal handling


SYNOPSIS

       #include <signal.h>

       void (*signal(int signum, void (*sighandler)(int)))(int);


DESCRIPTION

       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.


RETURN VALUE

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


PORTABILITY

       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­
       mended.

       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.

       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 (3.3.1.3) it is unspecified what hap­
       pens 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.


CONFORMING TO

       ANSI C


SEE ALSO

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


Man(1) output converted with man2html