This facility has been retained from the Base Document since the Committee felt it important to provide some standard mechanism for dealing with exceptional program conditions. Thus a subset of the signals defined in UNIX were retained in the Standard, along with the basic mechanisms of declaring signal handlers and (with adaptations, see §4.7.2.1) raising signals. For a discussion of the problems created by including signals, see §2.2.3.
The signal machinery contains many misnomers: SIGFPE, SIGILL, and SIGSEGV
have their roots in PDP-11 hardware terminology,
but the names are too entrenched to change.
(The occurrence of SIGFPE, for instance, does not necessarily
indicate a floating-point error.)
A conforming implementation is not required to field
any hardware interrupts.
The Committee has reserved the space of names beginning with
SIG to permit implementations to add local names to
<signal.h>.
This implies that such names should not be otherwise used in
a C source file which includes <signal.h>.
signal function
When a signal occurs
the normal flow of control of a program is interrupted.
If a signal occurs that is being trapped by a signal handler,
that handler is invoked.
When it is finished, execution continues at the
point at which the signal occurred.
This arrangement could cause problems if the
signal handler invokes a library function that was being executed at the
time of the signal.
Since library functions are not guaranteed to be re-entrant,
they should not be called from a signal handler that returns.
(See §2.2.3.)
A specific exception to this rule has been granted for calls to
signal from within the signal handler;
otherwise, the handler could not reliably reset the signal.
The specification that some signals may be effectively set to
SIG_IGN instead of SIG_DFL at program startup
allows programs under UNIX systems to
inherit this effective setting from parent processes.
For performance reasons, UNIX does not reset
SIGILL to default handling when the handler
is called (usually to emulate missing instructions).
This treatment is sanctioned by specifying that whether
reset occurs for SIGILL is
implementation-defined.
raise functionraise
replaces the Base Document's kill function.
The latter has an extra argument which refers to the ``process ID''
affected by the signal.
Since the execution model of the Standard does not deal with
multi-processing,
the Committee deemed it preferable to introduce a function which
requires no (dummy) process argument.
The Committee anticipates that IEEE 1003
will wish to standardize the kill function in the POSIX
specification.