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

FreeBSD Manual Pages

  
 
  

home | help
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  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.

RETURN VALUE
       The signal() function 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 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.

NOTES
       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  (3.3.1.3)  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.

CONFORMING TO
       ANSI C

SEE ALSO
       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)

NAME | SYNOPSIS | DESCRIPTION | RETURN VALUE | PORTABILITY | NOTES | CONFORMING TO | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=signal&sektion=2&manpath=Red+Hat+9>

home | help