Signal-Handling Functions

Using Signals Portably

The SAS/C signal-handling implementation offers many extensions that make it easier to use than a completely standard implementation. However, if you use these extensions, your programs are not portable. Keep in mind these considerations when writing a program that you intend to be portable:

Use only standard signals. These are SIGFPE , SIGSEGV , SIGILL , SIGINT , SIGABRT , and SIGTERM . Note that different implementations of C do not always generate signals for the same reasons. For example, in some implementations, a floating-point underflow may set the result to 0 instead of raising SIGFPE . The only signals that are guaranteed are those generated by calls to raise or abort .
Of all the functions available with this implementation of C, only raise and signal are in the ANSI Standard library. The remaining functions, which may be convenient, cannot be used in a portable program. The functions sigaction , sigprocmask , sigpending , and sigsuspend are portable to other systems that implement the POSIX 1003.1 standard.
A portable program must be able to deal with an interrupt at any time. A lot of code may be required to safely update linked lists and other data structures modified by the signal handler.
A portable program that needs to handle a signal repeatedly should call signal again immediately after entering the handler. This call minimizes the chance that the same signal will occur again and cause program termination.
Note: If you are writing programs to run only with the SAS/C library, you can delay calling signal until the end of the handler, because new asynchronous signals are not discovered until the handler returns, or signal is called. If you call signal at the beginning of the handler to reinstate signal handling, refer to the third list item.
Not all implementations support using longjmp in a signal handler. Also, in implementations other than SAS/C, library data may be left in an inconsistent state if longjmp is called in a handler after a library function is interrupted. This can cause unpredictable results if the same function or a related function is called again. (The SAS/C library uses the blkjmp function in many cases to intercept longjmp from a handler, so the problem should not arise in a SAS/C program, except for signals associated with ABEND.)
Most C library implementations are not re-entrant. For this reason, calling library functions other than longjmp , abort , exit , or signal from a handler is dangerous. This is especially true of memory allocation and I/O functions.
Because signals can occur between machine instructions, assignments or tests may be only partially completed at the time a signal occurs. If a handler updates data that are being modified or tested at the time of the signal and returns, the effects are unpredictable.
For maximum portability, your signal handlers should do the following:
1. reinstate signal handling by calling signal .
2. code the signal handler to assign a constant to a static volatile sig_atomic_t variable defined outside the handler. (The SAS/C library defines sig_atomic_t as char .)
3. return.
Then, in an appropriate area of the main code, test the static variable set by the handler to determine whether a signal has occurred. Even using this process, incorrect results can occur if the compiler optimizes references to the variable. Making the variable volatile may help prevent such optimizations.
All signal handlers should be defined to have the signum argument even if it is not used in the handler. Here is an example:
```
void int_handler(int signum)
```

Chapter Contents
Previous
Next
Top of Page