typedef void (*sighandler_t)(int);
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 the signal is blocked and sighandler is called with argument signum. The signal remains blocked during the execution of the signal handler.
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.
In a libc5 system including instead of makes signal to be redefined as bsd_signal__ and signal has the BSD semantics. This is not recommended.
In a glibc2 system defining a feature test macro such as _XOPEN_SOURCE or using a separate sysv_signal function, the classical behaviour is obtained. This is not recommended.
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 (22.214.171.124) 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.