Re: sigaction, SA_SIGINFO, and SIG_IGN

Eric Blake wrote: > it was failing to compile on mingw. Checking in this: To keep the *.m4 macros in sync with the code, I'm committing this: 2008-06-23 Bruno Haible <[EMAIL PROTECTED]> * m4/signalblocking.m4 (gl_PREREQ_SIG_HANDLER_H): Remove macro. (gl_PREREQ_SIGPROCMASK): D

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/21/2008 4:31 PM: | Done as follows, as part of committing sigaction. It turns out that since | mingw lacks struct sigaction, this only makes sense when using | sigaction(). I named the helper file sig-handler.h. I was a

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/22/2008 2:06 PM: | In the context of lib/fatal-signal.c, I find that SA_RESETHAND is not | appropriate: If a fatal signal handler cleanup is interrupted by another | fatal signal, it is better to start the cleanup a seco

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/22/2008 1:58 PM: | I don't understand the "Due to autoconf conventions". We are not using | HAVE_SIGACTION as a #define in config.h. We are using it as a shell variable. | This shell variable is not set by either AC_REPL

Re: sigaction, SA_SIGINFO, and SIG_IGN

In the context of lib/fatal-signal.c, I find that SA_RESETHAND is not appropriate: If a fatal signal handler cleanup is interrupted by another fatal signal, it is better to start the cleanup a second time rather than terminating the program with incomplete cleanup. OK to apply? 2008-06-22 Bruno

Re: sigaction, SA_SIGINFO, and SIG_IGN

The fact that the next POSIX calls siginterrupt 'obsolescent' is something that cannot be fixed by gnulib; therefore IMO it belongs outside the list of things that gnulib does not fix. Also, siginterrupt is related to SA_RESTART, not SA_NODEFER. 2008-06-22 Bruno Haible <[EMAIL PROTECTED]>

Re: sigaction, SA_SIGINFO, and SIG_IGN

I don't understand the "Due to autoconf conventions". We are not using HAVE_SIGACTION as a #define in config.h. We are using it as a shell variable. This shell variable is not set by either AC_REPLACE_FUNCS([sigaction]) nor by AC_CHECK_TYPE(...). So there is no conflict. Proposed comment change:

Re: sigaction, SA_SIGINFO, and SIG_IGN

In a comment you say that the mingw replacement for sigaction does not implement SA_RESTART. We can do better, since the msvcrt library never sets errno = EINTR anyway: Define SA_RESTART and ignore it. 2008-06-22 Bruno Haible <[EMAIL PROTECTED]> * lib/signal.in.h (SA_RESTART): New macr

Re: sigaction, SA_SIGINFO, and SIG_IGN

Since gl_SIGACTION may set HAVE_SIGACTION to its non-default value, the default value assignment must occur before it. 2008-06-22 Bruno Haible <[EMAIL PROTECTED]> * m4/sigaction.m4 (gl_SIGACTION): Invoke gl_SIGNAL_H_DEFAULTS. *** m4/sigaction.m4.orig2008-06-22 21:44:50.

Re: sigaction, SA_SIGINFO, and SIG_IGN

Eric Blake wrote: > I named the helper file sig-handler.h. Since it uses 'inline', it needs AC_C_INLINE. 2008-06-22 Bruno Haible <[EMAIL PROTECTED]> * m4/signalblocking.m4 (gl_PREREQ_SIG_HANDLER_H): New macro. (gl_PREREQ_SIGPROCMASK): Invoke it. * m4/sigaction.m4 (gl_P

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/20/2008 6:12 PM: |> 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-s

Re: sigaction, SA_SIGINFO, and SIG_IGN

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

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 6/20/2008 12:41 PM: | Bruno Haible <[EMAIL PROTECTED]> writes: | |> This will not compile on Interix 3.5, whereas the current code does. | | True; how about working around that problem by inserting the following | prelude i

Re: sigaction, SA_SIGINFO, and SIG_IGN

Bruno Haible <[EMAIL PROTECTED]> writes: > This will not compile on Interix 3.5, whereas the current code does. True; 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 s

Re: sigaction, SA_SIGINFO, and SIG_IGN

Jason Zions wrote about Interix 3.5: > Interix and the Vista/WS08 Subsystem for UNIX Applications do not include an > sa_sigaction member, as you point out, but they don't claim to conform to > the C Extensions or to IEEE Std 1003.1-2001. Then, if the system does not claim to conform to POSIX, you

Re: sigaction, SA_SIGINFO, and SIG_IGN

Paul Eggert wrote: > I'd feel a bit safer if we wrote the code to conform to POSIX rather > than assume the typical implementation where sa_handler and > sa_sigaction overlap. Sorry, I can't follow the argumentation. The set of systems where sa_handler and sa_sigaction are disjoint is empty, and y

Re: sigaction, SA_SIGINFO, and SIG_IGN

Bruno Haible <[EMAIL PROTECTED]> writes: > if (sigaction (fatal_signals[i], NULL, &action) >= 0 > + /* POSIX says that SIG_IGN can only occur when action.sa_flags > + does not contain SA_SIGINFO. But in Linux 2.4, for example, > + SA_SIGINFO can actuall

RE: sigaction, SA_SIGINFO, and SIG_IGN

The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously. -Original Message- From: Bruno Haible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 6:35 PM To: Eric Blake Cc: bug-gnulib@gnu.org Subject:

Re: sigaction, SA_SIGINFO, and SIG_IGN

Eric Blake wrote: > | POSIX is not correct about the type of SIG_DFL and SIG_IGN: > | In it says > | "... constants, each of which expands to a distinct constant expression > of > |the type void (*)(int) ...: SIG_DFL SIG_IGN" > | but

Re: sigaction, SA_SIGINFO, and SIG_IGN

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/17/2008 8:12 PM: | | Eric Blake wrote: |> |> |> if (sigaction (fatal_signals[i], NULL, &action) >= 0 |> |> + && (action.sa_flags & SA_SIGINFO) == 0 |> |> && action.sa_handler == SIG_IGN) |> |

Re: sigaction, SA_SIGINFO, and SIG_IGN

Eric Blake wrote: > |> struct sigaction action; > |> > |> if (sigaction (fatal_signals[i], NULL, &action) >= 0 > |> + && (action.sa_flags & SA_SIGINFO) == 0 > |> && action.sa_handler == SIG_IGN) > |>fatal_signals[i] = -1; > |>} > > Pre-existing bug. POS