The Committee also considered requiring that a call to longjmp restore the (setjmp) calling environment fully --- that upon execution of a longjmp, all local variables in the environment of setjmp have the values they did at the time of the longjmp call. Register variables create problems with this idea. Unfortunately, the best that many implementations attempt with register variables is to save them (in jmp_buf) at the time of the initial setjmp call, then restore them to that state on each return initiated by a longjmp call. Since compilers are certainly at liberty to change register variables to automatic, it is not obvious that a register declaration will indeed be rolled back. And since compilers are at liberty to change automatic variables to register (if their addresses are never taken), it is not obvious that an automatic declaration will not be rolled back. Hence the vague wording. In fact, the only reliable way to ensure that a local variable retain the value it had at the time of the call to longjmp is to define it with the volatile attribute.
Some implementations leave a process in a special state while a signal is being handled. An explicit reassurance must be given to the environment when the signal handler is done. To keep this job manageable, the Committee agreed to restrict longjmp to only one level of signal handling.
The longjmp function should not be called in an exit handler (i.e., a function registered with the atexit function (see .10.4.2)), since it might jump to some code which is no longer in scope.
4 7 Signal Handling<signal.h> <signal.h>
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 .7.2.1) raising signals.
For a discussion of the problems created by including signals,
see §
.
The signal machinery contains many misnomers:
[1]
SIGFPE, SIGILL, and SIGSEGV
have their roots in PDP-11 hardware terminology,
but the names are too entrenched to change.
add(The occurrence of SIGFPE, for instance, does not necessarily
indicate a floating-point error.)add
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>.
4 7 1