System 5.3.1 signal() replacement?

[Doug Gwyn]

In article <2914 at arcturus> evil at arcturus.UUCP (Wade Guthrie) writes:
>I noticed in an article about the
>dpANS (am I correct in assuming that this means something like the
>draft of the proposed ANSI standard?) the signal function -- how is the
>behavior of this specified, is it specified in a portable fashion or do
>they leave it up to the operating system?

ANSI C will specify signal() and minimal associated semantics for it,
just enough for applications to have a "fighting chance" at portable
use of signals.  Technically there are loopholes big enough to drive
an M1A1 through, but it is to be hoped that most implementations will
strive to provide usable signal facilities.  POSIX (IEEE Std 1003.1)
specifies a different interface that is considerably more robust, so
if you need to do much more than trap SIGINT to set an "interrupt
requested" shared flag (of type "volatile sig_atomic_t"), you're
advised to use the POSIX facilities instead of signal().

ANSI C signal() is specified so that either the traditional (until
4.2BSD changed it) reset to SIG_DFL upon entry to the handler occurs,
or some form of "blocking" (intended to be the POSIX reliable signal
mechanism) is performed for the signal that dispatched the handler.
Thus, portable applications need to invoke signal(sig,handler) as the
first thing in a signal handler, to reduce the window of vulnerability,
if the signal could occur during execution of the handler (not all
signals fall into that category.)  On reliable-signal systems, that
will be redundant but harmless.