Re: [4/10] RFC: unconditionally include signal.h

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 16 Nov 2012 17:25:09 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
> 
> > > I think that checking for signal.h is pointless, because gdb already
> > > includes it unconditionally in various places -- e.g., utils.c.
> > 
> > It's not pointless in gdbserver.  The HAVE_SIGNAL_H checks were added for
> > the WinCE port.  See fe7cf52e.
> 
> Should we consider using gnulib's signal.h?

In 2 out of 3 files in gdb/gdbserver/ that use HAVE_SIGNAL_H, the
references to signal facilities are already in code not compiled if
USE_WIN32API is defined.  So instead of using HAVE_SIGNAL_H, it
strikes me as better and more correct to use USE_WIN32API when
including signal.h -- this tells more clearly and honestly what is the
reason for not including signal.h and on what platforms.

The 3rd file (server.c) could use the same condition for including
signal.h -- the rest of the code that needs signals is carefully
conditioned on the respective signals being defined.

By contrast, gnulib's signal.h defines gobs of functions and macros
that we don't necessarily need, and could potentially mean more
trouble for WinCE, because (AFAIK) that platform is not supported by
gnulib anyway.