Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SIGNAL(2)		   Linux Programmer's Manual		     SIGNAL(2)

       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  ig-
       nored.  If the handler is set to	SIG_DFL, then the default action asso-
       ciated 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 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 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 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	seman-
       tics. 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.

       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 sig-
       nal.   (Also  dividing  the  most  negative  integer by -1 may generate
       SIGFPE.)	 Ignoring this signal might lead to an endless loop.

       According to POSIX  (  it  is  unspecified  what	 happens  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.

       The  use	 of sighandler_t is a GNU extension.  Various versions of libc
       predefine this type; libc4 and libc5 define  SignalHandler,  glibc  de-
       fines sig_t and,	when _GNU_SOURCE is defined, also sighandler_t.

       ANSI C

       kill(1),	 kill(2),  killpg(2),  pause(2),  raise(3), sigaction(2), sig-
       nal(7), sigsetops(3), sigvec(2),	alarm(2)

Linux 2.2			  2000-04-28			     SIGNAL(2)


Want to link to this manual page? Use this URL:

home | help