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

[Pedro Alves <palves at redhat dot com>]

On 11/17/2012 08:14 AM, Eli Zaretskii wrote:
>> 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.

I agree.

> 
> 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.

I agree.

Unlike non-CE Windows, CE doesn't really have any traces of signal numbers or
functions in its C runtime.  I still looks to me that guarding common/signals.c's
inclusion of signal.h with HAVE_SIGNAL_H describes the real issue in that case better
(unless we wanted to resort to platform checks, like #ifdef _WIN32_WCE, which we tend to
avoid). Replacing signal.h with a gnulib signal.h replacement that defines signals and
kill/signal/etc. from that perspective would kind of miss the point of
common/signals.c, which is to map host signals to gdb signals.

-- 
Pedro Alves