Re: [PATCH 0/5] replace signal() with sigaction()

[Chris Packham <judge.packham@gmail.com>]

On 28/05/14 19:40, Johannes Sixt wrote:
> Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
>> From signal(2)
>>
>>   The behavior of signal() varies across UNIX versions, and has also var‐
>>   ied historically across different versions of Linux.   Avoid  its  use:
>>   use sigaction(2) instead.  See Portability below.
>>
>> This patch set replaces calls to signal() with sigaction() in all files
>> except sigchain.c.  sigchain.c is a bit more complicated than the others
>> and will be done in a separate patch.
> 
> In compat/mingw.c we have:
> 
> int sigaction(int sig, struct sigaction *in, struct sigaction *out)
> {
> 	if (sig != SIGALRM)
> 		return errno = EINVAL,
> 			error("sigaction only implemented for SIGALRM");
> 	if (out != NULL)
> 		return errno = EINVAL,
> 			error("sigaction: param 3 != NULL not implemented");
> 
> 	timer_fn = in->sa_handler;
> 	return 0;
> }
> 
> Notice "only implemented for SIGALRM". Are adding the missing signals
> somewhere (here or in a later patch)?
> 

* note: not a windows/mingw programmer *

Will the ones setting SIG_IGN be OK? Presumably we won't get these
signals on windows anyway so we're already getting what we want.

>> Jeremiah Mahler (5):
>>   progress.c: replace signal() with sigaction()
>>   daemon.c run_service(): replace signal() with sigaction()
>>   daemon.c child_handler(): replace signal() with sigaction()
>>   daemon.c service_loop(): replace signal() with sigaction()
>>   connect.c: replace signal() with sigaction()
>>
>>  connect.c  |  5 ++++-
>>  daemon.c   | 15 ++++++++++++---
>>  progress.c |  6 +++++-
>>  3 files changed, 21 insertions(+), 5 deletions(-)
> 
> Isn't this a bit too much of code churn, given that there were no bug
> reports where signal handling is identified as the culprit despite
> the warning you cited above?
> 
> -- Hannes
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>