summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Mitchell <davem@iabyn.com>2019-11-12 10:47:30 +0000
committerDavid Mitchell <davem@iabyn.com>2019-11-18 09:34:40 +0000
commitc99d8cd6ea985084aa149f8f2b39217d6fc9068f (patch)
treea87ec7e46ad2890fd2853fdd8259d78bf90a49e8
parent19c9c2ee4a859f540f01b8d5592fd27d3fbfb253 (diff)
downloadperl-c99d8cd6ea985084aa149f8f2b39217d6fc9068f.tar.gz
declare perl core's sig handler as 1-arg
First some background: UNIXy OSes support two types of signal handler function: Signal_t handler1(int sig); Signal_t handler3(int sig, siginfo_t *info, void *uap); The original one-argument handler was set using the signal(2) system call. The newer sigaction(2) system call allows either a 1-arg or 3-arg handler to be specified: act.sa_handler = handler1; sigaction(sig, act, NULL); act.sa_sigaction = handler3; act.sa_sa_flags |= SA_SIGINFO; sigaction(sig, act, NULL); The current behaviour in perl core is that, in the presence of HAS_SIGACTION and SA_SIGINFO, the signal handler type and function are both declared as 3-arg, but perl still tells the kernel that the supplied signal handler function takes one arg. This means that whenever the kernel calls the handler, args 2 and 3 are whatever garbage the OS and architecture cause them to happen to be. Note that POSIX.xs *does* allow a 3-arg signal handler to be specified by passing the SA_SIGINFO flag, and a couple of tests check for this. Recently, gcc-8 has (quite reasonably) been warning that we're passing around 3-arg function pointers where a 1-arg function pointer is expected. After the groundwork laid down by the previous commits in this branch, this commit flips things over so that the perl core now declares its handlers and handler type as being 1-arg, thus reflecting the reality that the core has actually being using 1-arg handlers. This makes a whole bunch of compiler noise like this go away: perl.h:2825:51: warning: cast between incompatible function types from ‘__sighandler_t’ {aka ‘void (*)(int)’} to ‘void (*)(int, siginfo_t *, void *)’ {aka ‘void (*)(int, struct <anonymous> *, void *)’} [-Wcast-function-type] In theory this should make no functional difference. It might cause 3rd-party XS modules to emit compiler warnings now if they are relying on things like Sighandler_t to represent a 3-arg function - this commit flips it to being 1-arg.
-rw-r--r--ext/POSIX/POSIX.xs1
-rw-r--r--perl.h8
2 files changed, 7 insertions, 2 deletions
diff --git a/ext/POSIX/POSIX.xs b/ext/POSIX/POSIX.xs
index 3f7a2aafcf..31a4645562 100644
--- a/ext/POSIX/POSIX.xs
+++ b/ext/POSIX/POSIX.xs
@@ -3096,7 +3096,6 @@ sigaction(sig, optaction, oldaction = 0)
#endif
)
: ( oact.sa_handler == PL_csighandler1p
- || oact.sa_handler == PL_csighandlerp /* XXX tmp */
#ifndef PERL_USE_3ARG_SIGHANDLER
|| oact.sa_handler == PL_csighandlerp
#endif
diff --git a/perl.h b/perl.h
index 7d7a465851..1faa25502c 100644
--- a/perl.h
+++ b/perl.h
@@ -2795,7 +2795,13 @@ typedef struct padname PADNAME;
#if defined(HAS_SIGACTION) && defined(SA_SIGINFO)
-# define PERL_USE_3ARG_SIGHANDLER
+ /* having sigaction(2) means that the OS supports both 1-arg and 3-arg
+ * signal handlers. But the perl core itself only fully supports 1-arg
+ * handlers, so don't enable for now.
+ * NB: POSIX::sigaction() supports both.
+ *
+ * # define PERL_USE_3ARG_SIGHANDLER
+ */
#endif
/* Siginfo_t: