bug#13026: Assume POSIX 1003.1-1988 or later for signal.h.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 02 Dec 2012 17:31:48 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 13026@debbugs.gnu.org
> 
> On 11/30/2012 12:54 AM, Eli Zaretskii wrote:
> > Maybe a better fix there would be to
> > have an array of data (name and value of each signal), and loop
> > through it, instead of using if-elseif.
> 
> Sure, that's easy enough.  Gnulib already has a module to do that.
> Revised patch attached (most of the new stuff is just code
> copied from Gnulib).  As a bonus, this fixes signal-process to
> handle several signal names that it currently doesn't support,
> such as those of the real-time signals.

Thanks.

This will need additions to lib/makefile.w32-in, to get the new
modules to compile into libgnu.a.

> > By the way, an alternative way of dealing with the lack of Posix
> > signals on Windows is to condition the related fragments on WINDOWSNT,
> > and remove the "#ifdef SIGFOO" conditions for Posix signals.
> 
> I'd rather use the Autoconf style, which is to test for individual
> features rather than test for operating systems, as that tends to
> make maintenance easier when operating systems or the emulations
> mutate.

The likes of "#ifdef SIGFOO" are not Autoconf tests.  They test macros
defined in header files, exactly like "#ifdef WINDOWSNT" does.

The advantage of the latter is that it clearly says why, say, SIGTSTP
is not used unconditionally, which could otherwise puzzle someone who
knows that this signal is universally supported by Posix platforms.