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
