SIGNAL(3F)SIGNAL(3F)NAME
signal - change the action for a signal
SYNOPSIS
integer function signal(signum, proc, flag)
integer signum, flag
external proc
DESCRIPTION
When a process incurs a signal (see signal(3C)) the default action is usually to clean up and abort. The user may choose to write an
alternative signal handling routine. A call to signal is the way this alternate action is specified to the system.
Signum is the signal number (see signal(3C)). If flag is negative, then proc must be the name of the user signal handling routine. If
flag is zero or positive, then proc is ignored and the value of flag is passed to the system as the signal action definition. In particu-
lar, this is how previously saved signal actions can be restored. Two possible values for flag have specific meanings: 0 means "use the
default action" (See NOTES below), 1 means "ignore this signal".
A positive returned value is the previous action definition. A value greater than 1 is the address of a routine that was to have been
called on occurrence of the given signal. The returned value can be used in subsequent calls to signal in order to restore a previous
action definition. A negative returned value is the negation of a system error code. (See perror(3F))
FILES
/usr/lib/libU77.a
SEE ALSO signal(3C), kill(3F), kill(1)NOTES
f77 arranges to trap certain signals when a process is started. The only way to restore the default f77 action is to save the returned
value from the first call to signal.
If the user signal handler is called, it will be passed the signal number as an integer argument.
4.2 Berkeley Distribution May 15, 1985 SIGNAL(3F)
Check Out this Related Man Page
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
ignored. If the handler is set to SIG_DFL, then the default action associated to the signal (see signal(7)) occurs. Finally, if the han-
dler is set to a function sighandler then first either the handler is reset to SIG_DFL or an implementation-dependent blocking of the sig-
nal 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 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.
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
signal. (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, caus-
ing 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
defines 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), signal(7), sigsetops(3), sigvec(2), alarm(2)Linux 2.2 2000-04-28 SIGNAL(2)