bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sigaction, SA_SIGINFO, and SIG_IGN


From: Bruno Haible
Subject: Re: sigaction, SA_SIGINFO, and SIG_IGN
Date: Sat, 21 Jun 2008 02:12:33 +0200
User-agent: KMail/1.5.4

Hi Paul,

> how about working around that problem by inserting the following
> prelude into fatal-signal.c:
> 
>    typedef void (*sa_handler_t) (int);
> 
>    /* Return the handler of a signal, as a sa_handler_t value regardless
>       of its true type.  The resulting function can be compared to
>       special values like SIG_IGN but it is not portable to call it.  */
>    static sa_handler_t
>    get_handler (struct sigaction const *a)
>    {
>    #ifdef SA_SIGINFO
>      /* POSIX says that special values like SIG_IGN can only occur
>         when action.sa_flags does not contain SA_SIGINFO.  But in
>         Linux 2.4, for example, sa_sigaction and sa_handler are
>         aliases and a signal is ignored if sa_sigaction (after
>         casting) equals SIG_IGN.  So use (and cast) sa_sigaction in
>         that case.  */
>      if (a->sa_flags & SA_SIGINFO)
>        return (sa_handler_t) a->sa_sigaction;
>    #endif
>      return a->sa_handler;
>    }
> 
> and then using the following code in init_fatal_signals?
> 
>   if (sigaction (fatal_signals[i], NULL, &action) == 0
>       && get_handler (&action) == SIG_IGN)
>     fatal_signals[i] = -1;

This is acceptable to me. You are free to add this to lib/fatal-signal.c
(marking the function as "static inline", please).

Erik Blake wrote:
> Perhaps it would be nicer if the prelude were part of
> signal.in.h, so that both modules could use it?

Better use a private include file for it. signal.in.h is supposed to be
only the replacement for the POSIX/glibc <signal.h>. The fact that it's
used unconditionally by modules/signal is only a missed optimization.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]