RFC: removing old-style "signal" handling code

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> If 'sort' runs out of disk space or CPU time, it doesn't clean up its
> temporary files properly.  'ls' and 'csplit' have similar problems.  I
> noticed that 'sort', 'ls', and 'csplit' are not consistent about which
> signals they catch; it seems to me that they should be.  Which signals
> to catch is a bit of a judgment call, e.g., I have a program "alarm"
> such that "alarm 20 sort" runs 'sort' in an environment where it will
> get SIGALRM in 20 seconds, which is a nice utility to have.  So I was
> fairly conservative here, and listed in "The usual suspects."  a
> larger signal set than one might otherwise list.
>
> I considered putting the 'sig' array into a separate module to avoid
> duplication, but it didn't quite seem worth the hassle, as its
> contents aren't the same in ls.c.

I like the idea of factoring out that bunch of duplicated #ifdefs.
More importantly, the #if SA_NOCLDSTOP...#endif signal-handler-
initialization machinery is just begging to be factored out.

Regarding the catchable signal set, I was thinking of a function that'd
return a sigset_t with a bit set for each signal in some common set
(i.e., the union - SIGTSTP).  Then applications that need to add to or
subtract from that can use sigaddset or sigdelset.  But this works only
for systems with the sigaction interfaces.

Maybe we can finally excise the crufty code in those #else blocks.
Do any of you know of a "reasonable porting target" :-) that does
not define SA_NOCLDSTOP?  Here's a quick way to find out:

    printf '#include <signal.h>\n#ifndef SA_NOCLDSTOP\nRATS\n#endif\n' \
      | gcc -E -|grep '^RATS$'

If you don't have gcc, you can do this instead:

    printf '#include <signal.h>\n#ifndef SA_NOCLDSTOP\nRATS\n#endif\n' > k.c
    cc -E k.c |grep '^RATS$'

If it prints RATS, please tell us about your system, e.g., tell
us what these print:

    uname -a
    build-aux/config.guess