[Top][All Lists]
[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
- Re: sigaction, SA_SIGINFO, and SIG_IGN, (continued)
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/17
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/17
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/18
- RE: sigaction, SA_SIGINFO, and SIG_IGN, Jason Zions, 2008/06/18
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/19
- Re: Interix, Bruno Haible, 2008/06/19
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Paul Eggert, 2008/06/19
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/19
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Paul Eggert, 2008/06/20
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/20
- Re: sigaction, SA_SIGINFO, and SIG_IGN,
Bruno Haible <=
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/21
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/23
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Bruno Haible, 2008/06/22
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/23
- Re: sigaction, SA_SIGINFO, and SIG_IGN, Eric Blake, 2008/06/23