A signal that is not ignored by your program demands immediate handling. If you do not specify handling for a signal that occurs, it is treated as a fatal error. Your program terminates execution with unsuccessful status. In some implementations, the status indicates which signal occurred. In others, the Standard C library writes an error message to the standard error stream before it terminates execution.

The header <signal.h> defines the code values for an open-ended set of signals. It also declares two functions:

• raise, which reports a synchronous signal
• signal, which lets you specify the handling of a signal

• default handling is to terminate execution, as described above
• ignoring the signal effectively discards it
• handling the signal causes control to pass to a function that you designate

One problem is the Standard C library itself. If called with valid arguments, no library function should ever generate a synchronous signal. But an asynchronous signal can occur while the library is executing. The signal may suspend program execution part way through a print operation, for example. Should the signal handler print a message, an output stream can end up in a confused state. There is no way to determine from within a signal handler whether a library function is in an unsafe state.

Another problem concerns data objects that you declare to have volatile types. That warns the translator that surprising agents can access the data object, so it is careful how it generates accesses to such a data object. In particular, it knows not to perform optimizations that move the accesses to volatile data objects beyond certain sequence points. A signal handler is, of course, a surprising agent. Thus, you should declare any data object you access within a signal handler to have a volatile type. That helps, provided the signal is synchronous and occurs between two sequence points where the data object is not accessed. For an asynchronous signal however, no amount of protection suffices. Signals are not confined to suspending program execution only at sequence points.

The C Standard offers a partial solution to the problem of writing reliable signal handlers. The header <signal.h> defines the type sig_atomic_t. It is an integer type that the program accesses atomically. A signal should never suspend program execution part way through the access of a data object declared with this type. A signal handler can share with the rest of the program only data objects declared to have type volatile sig_atomic_t.

• Multiple signals could get lost. The system did not queue signals, but remembered only the last one reported. If a second signal occurred before a handler processed the first, a signal could go unnoticed.
• A program could terminate even when it endeavors to process all signals. When control first passes to a signal handler, handling for that signal reverts to default behavior. The signal handler must call signal to reestablish itself as the handler for the signal. Should that signal occur between entry to the handler and the call to signal, the default handler gets control and terminates the program.
• No mechanism exists for specifically terminating the handling of a signal. In other operating systems, the program enters a special state. Processing of subsequent signals blocks until the signal handler reports completion. On such systems, other functions may have to assist in processing signals properly. These can include abort and exit, declared in <stdlib.h>, and longjmp, declared in <setjmp.h>.

The C Standard had to weaken the already weak semantics of UNIX signals to accommodate an assortment of operating systems:

• A given signal may never occur unless you report it with raise.
• A given signal may be ignored unless you call signal to turn it on.

Thus, no portable use for the functions declared in <signal.h> can be defined with complete safety. You could, in principle, specify a handler for a signal that only raise reports. It's hard to imagine a situation where that works better than instead using setjmp and longjmp, declared in <setjmp.h>. Besides, you cannot ensure that a given signal is never reported on an arbitrary implementation of C. Any time your program handles signals, accept the fact that you limit its portability.

The type defined is

sig_atomic_t

The macros defined are

SIG_DFL
SIG_ERR
SIG_IGN

SIGABRT — abnormal termination, such as is initiated by the abort function

SIGFPE — an erroneous arithmetic operation, such as zero divide or an operation resulting in overflow

SIGILL — detection of an invalid function image, such as an illegal instruction

SIGINT — receipt of an interactive attention signal

SIGSEGV — an invalid access to storage

SIGTERM — a termination request sent to the program

An implementation need not generate any of these signals, except as a result of explicit calls to the raise function. Additional signals and pointers to undeclarable functions, with macro definitions beginning, respectively, with the letters SIG and an uppercase letter or with SIG_ and an uppercase letter,108 may also be specified by the implementation. The complete set of signals, their semantics, and their default handling is implementation-defined; all signal numbers shall be positive.

#include <signal.h>
void (*signal(int sig, void
(*func) (int))) (int);

When a signal occurs, if func points to a function, first the equivalent of signal(sig, SIG_DFL); is executed or an implementation-defined blocking of the signal is performed. (If the value of sig is SIGILL, whether the reset to SIG_DFL occurs is implementation-defined.) Next the equivalent of (*func) (sig); is executed. The function func may terminate by executing a return statement or by calling the abort, exit, or longjmp function. If func executes a return statement and the value of sig was SIGFPE or any other implementation-defined value corresponding to a computational exception, the behavior is undefined. Otherwise, the program will resume execution at the point it was interrupted.

If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler calls any function in the standard library other than the signal function itself (with a first argument of the signal number corresponding to the signal that caused the invocation of the handler) or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t. Furthermore, if such a call to the signal function results in a SIG_ERR return, the value of errno is indeterminate.109

At program startup, the equivalent of

signal (sig, SIG_IGN);

signal (sig, SIG_DFL);

The implementation shall behave as if no library function calls the signal function.

Forward references: the abort function (7.10.4.1), the exit function (7.10.4.3).

#include <signal .h>
int raise(int sig);

Footnotes:

108. See "future library directions" (7.13.5). The names of the signal numbers reflect the following terms (respectively): abort, floating-point exception, illegal instruction, interrupt, segmentation violation, and termination.

109. If any signal is generated by an asynchronous signal handler, the behavior is undefined.

If default handling for a signal is acceptable, then by all means choose that option. Adding your own signal handler decreases portability and raises the odds that the program will mishandle the signal. If you must provide a handler for a signal, categorize it as follows:

• a handler for a signal that must not return, such as SIGFPE reporting an arithmetic exception or SIGABRT reporting a fatal error
• a handler for a signal that must return, such as SIGINT reporting an attention interrupt that may have interrupted a library operation

A signal handler that must not return ends in a call to abort, exit, or longjmp. Do not, of course, end a handler for SIGABRT with a call to abort. The handler should not reestablish itself by calling signal. Leave that to some other agency, if the program does not terminate. If the signal is asynchronous, be wary of performing any input or output. You may have interrupted the library part way through such an operation.

A signal handler that must return ends in a return statement. If it is to reestablish itself, it should do so immediately on entry. If the signal is asynchronous, store a nonzero value in a volatile data object of type sig_atomic_t. Do nothing else that has side effects visible to the executing program, such as input or output and accessing other data objects.

A sample asynchronous signal handler might look like:

#include <signal.h>

static sig_atomic_t intflag = 0;

static void field_int(int sig)
   {   /* handle SIGINT */
   signal (SIGINT, &field_int);
   intflag = 1;
   return;
   }

if (intflag)
   {   /* act on interrupt */
   intflag = 0;
   .....
   }

• Within field_int before the call to signal, an occurrence of SIGINT can terminate the program.
• Between the testing and clearing of intflag, an occurrence of SIGINT can be lost.

SIGABRT — This signal occurs when the program is terminating unsuccessfully, as by an explicit call to abort, declared in <stdlib.h>. Do not ignore this signal. If you provide a handler, do as little as possible. End the handler with a return statement or a call to exit, declared in <stdlib.h>.

SIGFPE — The name originally meant "floating-point exception." The C Standard generalizes this signal to cover any arithmetic exception such as overflow, underflow, or zero divide. Implementations vary considerably on what exceptions they report, if any. Rarely does an implementation report integer overflow. Ignoring this signal may be rash. A handler must not return.

SIGINT — This is the conventional way of reporting an asynchronous interactive attention signal. Most systems provide some keystroke combination that you can type to generate such a signal. Examples are ctl-C, DEL, and ATTN. It offers a convenient way to terminate a tiresome loop early. But be aware that an asynchronous signal can catch the program part way through an operation that should be atomic. If the handler does not return control, the program may subsequently misbehave. You can safely ignore this signal.

SIGSEGV — The name originally meant "segmentation violation," because the PDP-11 managed memory as a set of segments. The C Standard generalizes this signal to cover any exception raised by an invalid storage access. The program has attempted to access storage outside any of the functions or data objects defined by C, as with an ill-formed function designator or lvalue. Or the program has attempted to store a value in a data object with a const type. In any event, the program cannot safely continue execution. Do not ignore this signal or return from its handler.

SIGTERM — This signal is traditionally sent from the operating system or from another program executing asynchronously with yours. Treat it as a polite but firm request to terminate execution. It is an asynchronous signal, so it may occur at an inopportune point in your program. You may want to defer it, using the techniques described above. You can ignore this signal safely, although it may be bad manners to do so.