[PATCH] config: check for sighandler_t properly

Nathan Sidwell nathan@acm.org
Mon Jan 25 18:14:29 GMT 2021


On 1/25/21 12:50 PM, Nick Alcock wrote:
> On 25 Jan 2021, Nathan Sidwell uttered the following:
> 
>> On 1/22/21 12:19 PM, Nick Alcock wrote:
>>> Searching for sighander_t is unlikely to succeed anywhere.
>>>
>>> The attempt to #include <sys/signal.h> is also not working,
>>> and fixing it shows that doing an AC_DEFINE in the body of
>>> an AC_CHECK_TYPE like that is also risky: both fixed.
>>>
>>> (The purpose of this check is opaque to me: neither libcody
>>> nor GCC ever includes <sys/signal.h>, and though <signal.h> is
>>> widely included, it is not directly included by any of the
>>> headers checking this macro...  for now I've fixed things
>>> to conform to the comment, but perhaps we should be checking
>>> the non-deprecated <signal.h> instead, and #including it
>>> in mapper-client.h?)
>>
>> Thanks for noticint this.  I think this is left over from earlier module-mapper predating its move (and changes) to c++tools.  If
>> you'd like to remove that entire bit of configure.ac, that'd be great (or I can do so, if you don't have time)
> 
> The sig_handler_t does appear to be still used, albeit not much: it's
> used by mapper-client.h for the module_client::sigpipe declaration,
> which is then used by the module mapper, which does appear to be still
> used from elsewhere in module.c.

Oh, I recall now.  We have to ignore SIGPIPE when using a pair of pipes 
to communicate between compiler and mapper.  Otherwise the compiler can 
die awfully if the mapper goes away (though maybe that's the behaviour 
we'd now want?)

I think you're right about checking <signal.h> though, not <sys/signal.h>


-- 
Nathan Sidwell


More information about the Gcc-patches mailing list