1-arg and 3-arg signal handlers

I've just pushed the following commit (smoke-me/davem/sighandler) for
smoking and possible discussion. I'd especially like feedback for
non-POSIX platforms: I have no idea whether this commit breaks signals on
those platforms.

(No idea whether I should be making this into a PR or something).

commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9
Author:     David Mitchell <davem@iabyn.com>
AuthorDate: Thu Oct 17 13:42:55 2019 +0100
Commit:     David Mitchell <davem@iabyn.com>
CommitDate: Mon Nov 4 11:23:51 2019 +0000

    Rationalise perl's OS-level signal handler
    
    First some background:
    
    UNIXy OSes support two type 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. Furthermore, some code in
    the handler uses the nullness of args 2 and 3 to decide whether it has
    been called by the kernel, or explicitly as handler(sig,NULL,NULL).
    The fact that this condition works has just been down to luck so far.
    
    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 been (quite reasonably) warning that we're passing
    around 3-arg function pointers where a 1-arg function pointer is
    expected.
    
    This commit does the following:
    
    1) It adds a new function, Perl_perly_sighandler() which is just
    responsible for calling the perl-level $SIG{FOO} handler sub. This new
    function may either be called directly by Perl_csighandler (for unsafe
    signals), or called later by Perl_despatch_signals() for the more
    normal safe signal regime. It has the 3 sig handler args, plus a fourth
    boolean arg which indicates whether it is being called in safe mode.
    
    2) It adds explicit 1-arg and 3-arg variants of the C-level signal
    handler functions sighandler1() and sigghandler3(), while the existing
    function sighandler() has a signature which depends on the value of
    PERL_USE_3ARG_SIGHANDLER.
    
`    3) It disables PERL_USE_3ARG_SIGHANDLER by default. This means that
    declarations such as Sighandler_t are now 1-arg to match the fact that
    perl core is (as before) actually using a 1-arg handler most of the
    time.
    
    This commit isn't a complete fix: in particular using 3-arg handlers by
    default by enabling PERL_USE_3ARG_SIGHANDLER doesn't yet pass all tests.
    That is left as an exercise to the reader.
    
    In summary, perl continues to use 1-arg signal handlers, but now
    declares its handlers as 1-arg rather than 3-arg, so a bunch of compiler
    warnings go away. Also, the code is now more rational and better
    commented, so that moving to 3-arg handlers in the future won't be so
    hard.


-- 
In England there is a special word which means the last sunshine
of the summer. That word is "spring".
0
davem
11/4/2019 11:59:58 AM
perl.perl5.porters 47860 articles. 1 followers. Follow

13 Replies
19 Views

Similar Articles

[PageSpeed] 32

On 11/4/19 6:59 AM, Dave Mitchell wrote:
> I've just pushed the following commit (smoke-me/davem/sighandler) for
> smoking and possible discussion. I'd especially like feedback for
> non-POSIX platforms: I have no idea whether this commit breaks signals on
> those platforms.
> 
> (No idea whether I should be making this into a PR or something).

Thanks for this work.  Since, as you describe below, this is a 
work-in-progress, a smoke-me branch is, IMO, a good approach.  (A pull 
request seems premature.)

> 
> commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9
> Author:     David Mitchell <davem@iabyn.com>
> AuthorDate: Thu Oct 17 13:42:55 2019 +0100
> Commit:     David Mitchell <davem@iabyn.com>
> CommitDate: Mon Nov 4 11:23:51 2019 +0000
> 
>      Rationalise perl's OS-level signal handler
>      
>      First some background:
>      
>      UNIXy OSes support two type 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. Furthermore, some code in
>      the handler uses the nullness of args 2 and 3 to decide whether it has
>      been called by the kernel, or explicitly as handler(sig,NULL,NULL).
>      The fact that this condition works has just been down to luck so far.
>      
>      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 been (quite reasonably) warning that we're passing
>      around 3-arg function pointers where a 1-arg function pointer is
>      expected.
>      
>      This commit does the following:
>      
>      1) It adds a new function, Perl_perly_sighandler() which is just
>      responsible for calling the perl-level $SIG{FOO} handler sub. This new
>      function may either be called directly by Perl_csighandler (for unsafe
>      signals), or called later by Perl_despatch_signals() for the more
>      normal safe signal regime. It has the 3 sig handler args, plus a fourth
>      boolean arg which indicates whether it is being called in safe mode.
>      
>      2) It adds explicit 1-arg and 3-arg variants of the C-level signal
>      handler functions sighandler1() and sigghandler3(), while the existing
>      function sighandler() has a signature which depends on the value of
>      PERL_USE_3ARG_SIGHANDLER.
>      
> `    3) It disables PERL_USE_3ARG_SIGHANDLER by default. This means that
>      declarations such as Sighandler_t are now 1-arg to match the fact that
>      perl core is (as before) actually using a 1-arg handler most of the
>      time.
>      
>      This commit isn't a complete fix: in particular using 3-arg handlers by
>      default by enabling PERL_USE_3ARG_SIGHANDLER doesn't yet pass all tests.
>      That is left as an exercise to the reader.
>      
>      In summary, perl continues to use 1-arg signal handlers, but now
>      declares its handlers as 1-arg rather than 3-arg, so a bunch of compiler
>      warnings go away. Also, the code is now more rational and better
>      commented, so that moving to 3-arg handlers in the future won't be so
>      hard.

Can you provide more detail as to which compiler warnings go away?  How 
would I configure perl to generate the kind of warnings eliminated by 
this branch?

(I'd like to do before/after comparisons, but, apart from warnings 
generated by upstream libraries as in IO::Compress, right now I don't 
get many warnings during 'make'.)

Thank you very much.
Jim Keenan

> 
> 
0
jkeenan
11/4/2019 12:12:23 PM
On 11/4/19 6:59 AM, Dave Mitchell wrote:
> I've just pushed the following commit (smoke-me/davem/sighandler) for
> smoking and possible discussion. I'd especially like feedback for
> non-POSIX platforms: I have no idea whether this commit breaks signals on
> those platforms.
> 
> (No idea whether I should be making this into a PR or something).
> 
> commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9
> Author:     David Mitchell <davem@iabyn.com>
> AuthorDate: Thu Oct 17 13:42:55 2019 +0100
> Commit:     David Mitchell <davem@iabyn.com>
> CommitDate: Mon Nov 4 11:23:51 2019 +0000
> 
>      Rationalise perl's OS-level signal handler
>      
>      First some background:
>      
>      UNIXy OSes support two type 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. Furthermore, some code in
>      the handler uses the nullness of args 2 and 3 to decide whether it has
>      been called by the kernel, or explicitly as handler(sig,NULL,NULL).
>      The fact that this condition works has just been down to luck so far.
>      
>      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 been (quite reasonably) warning that we're passing
>      around 3-arg function pointers where a 1-arg function pointer is
>      expected.
>      
>      This commit does the following:
>      
>      1) It adds a new function, Perl_perly_sighandler() which is just
>      responsible for calling the perl-level $SIG{FOO} handler sub. This new
>      function may either be called directly by Perl_csighandler (for unsafe
>      signals), or called later by Perl_despatch_signals() for the more
>      normal safe signal regime. It has the 3 sig handler args, plus a fourth
>      boolean arg which indicates whether it is being called in safe mode.
>      
>      2) It adds explicit 1-arg and 3-arg variants of the C-level signal
>      handler functions sighandler1() and sigghandler3(), while the existing
>      function sighandler() has a signature which depends on the value of
>      PERL_USE_3ARG_SIGHANDLER.
>      
> `    3) It disables PERL_USE_3ARG_SIGHANDLER by default. This means that
>      declarations such as Sighandler_t are now 1-arg to match the fact that
>      perl core is (as before) actually using a 1-arg handler most of the
>      time.
>      
>      This commit isn't a complete fix: in particular using 3-arg handlers by
>      default by enabling PERL_USE_3ARG_SIGHANDLER doesn't yet pass all tests.
>      That is left as an exercise to the reader.
>      
>      In summary, perl continues to use 1-arg signal handlers, but now
>      declares its handlers as 1-arg rather than 3-arg, so a bunch of compiler
>      warnings go away. Also, the code is now more rational and better
>      commented, so that moving to 3-arg handlers in the future won't be so
>      hard.
> 
> 

The branch doesn't include any new tests.  Given the change of behavior, 
that seems surprising.

Thank you very much.
Jim Keenan
0
jkeenan
11/4/2019 12:28:52 PM
On Mon, 4 Nov 2019 07:12:23 -0500
James E Keenan <jkeenan@pobox.com> wrote:

> On 11/4/19 6:59 AM, Dave Mitchell wrote:
> > I've just pushed the following commit (smoke-me/davem/sighandler) for
> > smoking and possible discussion. I'd especially like feedback for
> > non-POSIX platforms: I have no idea whether this commit breaks signals on
> > those platforms.
> >
> > (No idea whether I should be making this into a PR or something).
> 
> Thanks for this work.  Since, as you describe below, this is a work-in-progress, a smoke-me branch is, IMO, a good approach.  (A pull request seems premature.)

I don't agree, despite the name, PRs are also a tool for code reviews.
0
me
11/4/2019 2:35:34 PM
--00000000000008ec6f05968fb934
Content-Type: text/plain; charset="UTF-8"

Hi,
The smoke-me/davem/sighandler branch didn't go at all well for me on
Windows 7, using mingw-w64 port of gcc-8.3.0.
Running 'gmake' fails immediately with:

# CCTYPE=GCC
# GCCBIN=gcc
# GCCVER=8.3.0
# GCCTARGET=x86_64-w64-mingw32
# GCCCROSS=
# WIN64=define
# ARCHITECTURE=x64
# ARCHNAME=MSWin32-x64-multi-thread
# MAKE=gmake
if not exist "mini" mkdir "mini"
copy config_H.gc config.h
        1 file(s) copied.
gcc -c  -I.\include -I. -I.. -DWIN32 -DWIN64 -DPERLDLL -DPERL_CORE -s -O2
 -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GLOB
-DPERL_IS_
MINIPERL -omini\toke.o  ..\toke.c
In file included from ..\perl.h:3799,
                 from ..\toke.c:40:
...\iperlsys.h:54:41: error: unknown type name 'siginfo_t'; did you mean
'ioinfo'
?
 typedef Signal_t (*Sighandler3_t) (int, siginfo_t*, void*);
                                         ^~~~~~~~~
                                         ioinfo
In file included from ..\perl.h:5473,
                 from ..\toke.c:40:
...\proto.h:706:51: error: unknown type name 'siginfo_t'; did you mean
'ioinfo'?
 PERL_CALLCONV Signal_t Perl_csighandler3(int sig, siginfo_t *info, void
*uap);
                                                   ^~~~~~~~~
                                                   ioinfo
...\proto.h:2651:55: error: unknown type name 'siginfo_t'; did you mean
'ioinfo'?

 PERL_CALLCONV Signal_t Perl_perly_sighandler(int sig, siginfo_t *info,
void *uap, bool safe);
                                                       ^~~~~~~~~
                                                       ioinfo
...\proto.h:3122:50: error: unknown type name 'siginfo_t'; did you mean
'ioinfo'?

 PERL_CALLCONV Signal_t Perl_sighandler3(int sig, siginfo_t *info, void
*uap);
                                                  ^~~~~~~~~
                                                  ioinfo
In file included from ..\toke.c:40:
...\intrpvar.h:616:26: error: unknown type name 'Sighandler3_t'
 PERLVAR(I, sighandler3p, Sighandler3_t)
                          ^~~~~~~~~~~~~
...\perl.h:5489:38: note: in definition of macro 'PERLVAR'
 #define PERLVAR(prefix,var,type) EXT type PL_##var;
                                      ^~~~
...\perlvars.h:82:28: error: unknown type name 'Sighandler3_t'
 PERLVARI(G, csighandler3p, Sighandler3_t, Perl_csighandler3)
                            ^~~~~~~~~~~~~
...\perl.h:5491:44: note: in definition of macro 'PERLVARI'
 #define PERLVARI(prefix,var,type,init) EXT type  PL_##var INIT(init);
                                            ^~~~
In file included from ..\toke.c:40:
...\intrpvar.h:616:26: error: unknown type name 'Sighandler3_t'
 PERLVAR(I, sighandler3p, Sighandler3_t)
                          ^~~~~~~~~~~~~
...\perl.h:5529:36: note: in definition of macro 'PERLVAR'
 #  define PERLVAR(prefix,var,type) type prefix##var;
                                    ^~~~
make: *** [GNUmakefile:1523: mini\toke.o] Error 1

Cheers,
Rob

On Mon, Nov 4, 2019 at 11:00 PM Dave Mitchell <davem@iabyn.com> wrote:

> I've just pushed the following commit (smoke-me/davem/sighandler) for
> smoking and possible discussion. I'd especially like feedback for
> non-POSIX platforms: I have no idea whether this commit breaks signals on
> those platforms.
>
> (No idea whether I should be making this into a PR or something).
>
> commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9
> Author:     David Mitchell <davem@iabyn.com>
> AuthorDate: Thu Oct 17 13:42:55 2019 +0100
> Commit:     David Mitchell <davem@iabyn.com>
> CommitDate: Mon Nov 4 11:23:51 2019 +0000
>
>     Rationalise perl's OS-level signal handler
>
>     First some background:
>
>     UNIXy OSes support two type 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. Furthermore, some code in
>     the handler uses the nullness of args 2 and 3 to decide whether it has
>     been called by the kernel, or explicitly as handler(sig,NULL,NULL).
>     The fact that this condition works has just been down to luck so far.
>
>     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 been (quite reasonably) warning that we're passing
>     around 3-arg function pointers where a 1-arg function pointer is
>     expected.
>
>     This commit does the following:
>
>     1) It adds a new function, Perl_perly_sighandler() which is just
>     responsible for calling the perl-level $SIG{FOO} handler sub. This new
>     function may either be called directly by Perl_csighandler (for unsafe
>     signals), or called later by Perl_despatch_signals() for the more
>     normal safe signal regime. It has the 3 sig handler args, plus a fourth
>     boolean arg which indicates whether it is being called in safe mode.
>
>     2) It adds explicit 1-arg and 3-arg variants of the C-level signal
>     handler functions sighandler1() and sigghandler3(), while the existing
>     function sighandler() has a signature which depends on the value of
>     PERL_USE_3ARG_SIGHANDLER.
>
> `    3) It disables PERL_USE_3ARG_SIGHANDLER by default. This means that
>     declarations such as Sighandler_t are now 1-arg to match the fact that
>     perl core is (as before) actually using a 1-arg handler most of the
>     time.
>
>     This commit isn't a complete fix: in particular using 3-arg handlers by
>     default by enabling PERL_USE_3ARG_SIGHANDLER doesn't yet pass all
> tests.
>     That is left as an exercise to the reader.
>
>     In summary, perl continues to use 1-arg signal handlers, but now
>     declares its handlers as 1-arg rather than 3-arg, so a bunch of
> compiler
>     warnings go away. Also, the code is now more rational and better
>     commented, so that moving to 3-arg handlers in the future won't be so
>     hard.
>
>
> --
> In England there is a special word which means the last sunshine
> of the summer. That word is "spring".
>

--00000000000008ec6f05968fb934
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div>The smoke-me/davem/sighandler branch di=
dn&#39;t go at all well for me on Windows 7, using mingw-w64 port of gcc-8.=
3.0.</div><div>Running &#39;gmake&#39; fails immediately with:</div><div><b=
r></div><div># CCTYPE=3DGCC<br># GCCBIN=3Dgcc<br># GCCVER=3D8.3.0<br># GCCT=
ARGET=3Dx86_64-w64-mingw32<br># GCCCROSS=3D<br># WIN64=3Ddefine<br># ARCHIT=
ECTURE=3Dx64<br># ARCHNAME=3DMSWin32-x64-multi-thread<br># MAKE=3Dgmake</di=
v><div>if not exist &quot;mini&quot; mkdir &quot;mini&quot;<br>copy config_=
H.gc config.h<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1 file(s) copied.<br>gcc -c =
=C2=A0-I.\include -I. -I.. -DWIN32 -DWIN64 -DPERLDLL -DPERL_CORE -s -O2 =C2=
=A0-D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GL=
OB -DPERL_IS_<br>MINIPERL -omini\toke.o =C2=A0..\toke.c<br>In file included=
 from ..\perl.h:3799,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0from ..\toke.c:40:<br>..\iperlsys.h:54:41: error: unknown type=
 name &#39;siginfo_t&#39;; did you mean &#39;ioinfo&#39;<br>?<br>=C2=A0type=
def Signal_t (*Sighandler3_t) (int, siginfo_t*, void*);<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ioinfo=
<br>In file included from ..\perl.h:5473,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from ..\toke.c:40:<br>..\proto.h:706:51: =
error: unknown type name &#39;siginfo_t&#39;; did you mean &#39;ioinfo&#39;=
?<br>=C2=A0PERL_CALLCONV Signal_t Perl_csighandler3(int sig, siginfo_t *inf=
o, void *uap);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0ioinfo<br>..\proto.h:2651:55: error: unknown type n=
ame &#39;siginfo_t&#39;; did you mean &#39;ioinfo&#39;?<br><br>=C2=A0PERL_C=
ALLCONV Signal_t Perl_perly_sighandler(int sig, siginfo_t *info, void *uap,=
 bool safe);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ioinfo<br>..\proto.h:3122:5=
0: error: unknown type name &#39;siginfo_t&#39;; did you mean &#39;ioinfo&#=
39;?<br><br>=C2=A0PERL_CALLCONV Signal_t Perl_sighandler3(int sig, siginfo_=
t *info, void *uap);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ioinfo<br>In file included from ..\toke.c:40:<br>..\in=
trpvar.h:616:26: error: unknown type name &#39;Sighandler3_t&#39;<br>=C2=A0=
PERLVAR(I, sighandler3p, Sighandler3_t)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~<b=
r>..\perl.h:5489:38: note: in definition of macro &#39;PERLVAR&#39;<br>=C2=
=A0#define PERLVAR(prefix,var,type) EXT type PL_##var;<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~<br>..\perlvars.h:82:28: erro=
r: unknown type name &#39;Sighandler3_t&#39;<br>=C2=A0PERLVARI(G, csighandl=
er3p, Sighandler3_t, Perl_csighandler3)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~=
~~~~~<br>..\perl.h:5491:44: note: in definition of macro &#39;PERLVARI&#39;=
<br>=C2=A0#define PERLVARI(prefix,var,type,init) EXT type =C2=A0PL_##var IN=
IT(init);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ^~~~<br>In file included from ..\toke.c:40:<br>..\intrpva=
r.h:616:26: error: unknown type name &#39;Sighandler3_t&#39;<br>=C2=A0PERLV=
AR(I, sighandler3p, Sighandler3_t)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~<br>..=
\perl.h:5529:36: note: in definition of macro &#39;PERLVAR&#39;<br>=C2=A0# =
=C2=A0define PERLVAR(prefix,var,type) type prefix##var;<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~<br>make: *** [GNUmakefile:1523:=
 mini\toke.o] Error 1</div><div><br></div><div>Cheers,</div><div>Rob<br></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Mon, Nov 4, 2019 at 11:00 PM Dave Mitchell &lt;<a href=3D"mailto:dave=
m@iabyn.com">davem@iabyn.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">I&#39;ve just pushed the following commit (smok=
e-me/davem/sighandler) for<br>
smoking and possible discussion. I&#39;d especially like feedback for<br>
non-POSIX platforms: I have no idea whether this commit breaks signals on<b=
r>
those platforms.<br>
<br>
(No idea whether I should be making this into a PR or something).<br>
<br>
commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9<br>
Author:=C2=A0 =C2=A0 =C2=A0David Mitchell &lt;<a href=3D"mailto:davem@iabyn=
..com" target=3D"_blank">davem@iabyn.com</a>&gt;<br>
AuthorDate: Thu Oct 17 13:42:55 2019 +0100<br>
Commit:=C2=A0 =C2=A0 =C2=A0David Mitchell &lt;<a href=3D"mailto:davem@iabyn=
..com" target=3D"_blank">davem@iabyn.com</a>&gt;<br>
CommitDate: Mon Nov 4 11:23:51 2019 +0000<br>
<br>
=C2=A0 =C2=A0 Rationalise perl&#39;s OS-level signal handler<br>
<br>
=C2=A0 =C2=A0 First some background:<br>
<br>
=C2=A0 =C2=A0 UNIXy OSes support two type of signal handler function:<br>
<br>
=C2=A0 =C2=A0 Signal_t handler1(int sig);<br>
=C2=A0 =C2=A0 Signal_t handler3(int sig, siginfo_t *info, void *uap);<br>
<br>
=C2=A0 =C2=A0 The original one-argument handler was set using the signal(2)=
 system<br>
=C2=A0 =C2=A0 call. The newer sigaction(2) system call allows either a 1-ar=
g or<br>
=C2=A0 =C2=A0 3-arg handler to be specified:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 act.sa_handler =3D handler1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sigaction(sig, act, NULL);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 act.sa_sigaction =3D handler3;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 act.sa_sa_flags |=3D SA_SIGINFO;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sigaction(sig, act, NULL);<br>
<br>
=C2=A0 =C2=A0 The current behaviour in perl core is that, in the presence o=
f<br>
=C2=A0 =C2=A0 HAS_SIGACTION and SA_SIGINFO, the signal handler type and fun=
ction are<br>
=C2=A0 =C2=A0 both declared as 3-arg, but perl still tells the kernel that =
the<br>
=C2=A0 =C2=A0 supplied signal handler function takes one arg. This means th=
at whenever<br>
=C2=A0 =C2=A0 the kernel calls the handler, args 2 and 3 are whatever garba=
ge the OS<br>
=C2=A0 =C2=A0 and architecture cause them to happen to be. Furthermore, som=
e code in<br>
=C2=A0 =C2=A0 the handler uses the nullness of args 2 and 3 to decide wheth=
er it has<br>
=C2=A0 =C2=A0 been called by the kernel, or explicitly as handler(sig,NULL,=
NULL).<br>
=C2=A0 =C2=A0 The fact that this condition works has just been down to luck=
 so far.<br>
<br>
=C2=A0 =C2=A0 Note that POSIX.xs does allow a 3-arg signal handler to be sp=
ecified by<br>
=C2=A0 =C2=A0 passing the SA_SIGINFO flag, and a couple of tests check for =
this.<br>
<br>
=C2=A0 =C2=A0 Recently, gcc-8 has been (quite reasonably) warning that we&#=
39;re passing<br>
=C2=A0 =C2=A0 around 3-arg function pointers where a 1-arg function pointer=
 is<br>
=C2=A0 =C2=A0 expected.<br>
<br>
=C2=A0 =C2=A0 This commit does the following:<br>
<br>
=C2=A0 =C2=A0 1) It adds a new function, Perl_perly_sighandler() which is j=
ust<br>
=C2=A0 =C2=A0 responsible for calling the perl-level $SIG{FOO} handler sub.=
 This new<br>
=C2=A0 =C2=A0 function may either be called directly by Perl_csighandler (f=
or unsafe<br>
=C2=A0 =C2=A0 signals), or called later by Perl_despatch_signals() for the =
more<br>
=C2=A0 =C2=A0 normal safe signal regime. It has the 3 sig handler args, plu=
s a fourth<br>
=C2=A0 =C2=A0 boolean arg which indicates whether it is being called in saf=
e mode.<br>
<br>
=C2=A0 =C2=A0 2) It adds explicit 1-arg and 3-arg variants of the C-level s=
ignal<br>
=C2=A0 =C2=A0 handler functions sighandler1() and sigghandler3(), while the=
 existing<br>
=C2=A0 =C2=A0 function sighandler() has a signature which depends on the va=
lue of<br>
=C2=A0 =C2=A0 PERL_USE_3ARG_SIGHANDLER.<br>
<br>
`=C2=A0 =C2=A0 3) It disables PERL_USE_3ARG_SIGHANDLER by default. This mea=
ns that<br>
=C2=A0 =C2=A0 declarations such as Sighandler_t are now 1-arg to match the =
fact that<br>
=C2=A0 =C2=A0 perl core is (as before) actually using a 1-arg handler most =
of the<br>
=C2=A0 =C2=A0 time.<br>
<br>
=C2=A0 =C2=A0 This commit isn&#39;t a complete fix: in particular using 3-a=
rg handlers by<br>
=C2=A0 =C2=A0 default by enabling PERL_USE_3ARG_SIGHANDLER doesn&#39;t yet =
pass all tests.<br>
=C2=A0 =C2=A0 That is left as an exercise to the reader.<br>
<br>
=C2=A0 =C2=A0 In summary, perl continues to use 1-arg signal handlers, but =
now<br>
=C2=A0 =C2=A0 declares its handlers as 1-arg rather than 3-arg, so a bunch =
of compiler<br>
=C2=A0 =C2=A0 warnings go away. Also, the code is now more rational and bet=
ter<br>
=C2=A0 =C2=A0 commented, so that moving to 3-arg handlers in the future won=
&#39;t be so<br>
=C2=A0 =C2=A0 hard.<br>
<br>
<br>
-- <br>
In England there is a special word which means the last sunshine<br>
of the summer. That word is &quot;spring&quot;.<br>
</blockquote></div>

--00000000000008ec6f05968fb934--
0
sisyphus359
11/5/2019 1:54:54 AM
On Mon, Nov 04, 2019 at 07:28:52AM -0500, James E Keenan wrote:
> The branch doesn't include any new tests.  Given the change of behavior,
> that seems surprising.

There isn't supposed to be any change in behaviour.

> Can you provide more detail as to which compiler warnings go away?  How
> would I configure perl to generate the kind of warnings eliminated by this
> branch?

On recent GCC's (8-ish), lots of stuff like

perl.h:2821: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]



-- 
"I used to be with it, but then they changed what ‘it’ was, and now what
I’m with isn’t it. And what’s ‘it’ seems weird and scary to me."
  -- Grandpa Simpson
(It will happen to you too.)
0
davem
11/5/2019 11:52:00 AM
On 11/4/19 4:59 AM, Dave Mitchell wrote:
> I've just pushed the following commit (smoke-me/davem/sighandler) for
> smoking and possible discussion. I'd especially like feedback for
> non-POSIX platforms: I have no idea whether this commit breaks signals =
on
> those platforms.
>=20
> (No idea whether I should be making this into a PR or something).

I see these warnings in an SuSE smoke from Tux

   embed.h:474:44: note: in definition of macro =E2=80=98rsignal=E2=80=99
   util.c: In function =E2=80=98Perl_rsignal=E2=80=99:
   util.c:2716:22: warning: cast between incompatible function types=20
from =E2=80=98Sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int,  struct  =
*, void *)=E2=80=99} to =E2=80=98void=20
(*)(int)=E2=80=99 [-Wcast-function-type]
   util.c:2724:40: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   util.c:2728:13: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   util.c:2730:13: warning: cast between incompatible function types=20
from =E2=80=98__sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int)=E2=80=99=
} to =E2=80=98void (*)(int,  siginfo_t=20
*, void *)=E2=80=99 {aka =E2=80=98void (*)(int,  struct  *, void *)=E2=80=
=99} [-Wcast-function-type]
   util.c: In function =E2=80=98Perl_rsignal_state=E2=80=99:
   util.c:2740:9: warning: cast between incompatible function types from=20
=E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t *, v=
oid *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   util.c:2742:9: warning: cast between incompatible function types from=20
=E2=80=98__sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int)=E2=80=99} to=
 =E2=80=98void (*)(int,  siginfo_t *,=20
void *)=E2=80=99 {aka =E2=80=98void (*)(int,  struct  *, void *)=E2=80=99=
} [-Wcast-function-type]
   util.c: In function =E2=80=98Perl_rsignal_save=E2=80=99:
   util.c:2761:22: warning: cast between incompatible function types=20
from =E2=80=98Sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int,  struct  =
*, void *)=E2=80=99} to =E2=80=98void=20
(*)(int)=E2=80=99 [-Wcast-function-type]
   util.c:2769:40: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   mg.c: In function =E2=80=98Perl_magic_getsig=E2=80=99:
   mg.c:1470:25: warning: cast between incompatible function types from=20
=E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t *, v=
oid *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   mg.c: In function =E2=80=98Perl_magic_setsig=E2=80=99:
   mg.c:1747:20: warning: cast between incompatible function types from=20
=E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t *, v=
oid *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   mg.c:1757:20: warning: cast between incompatible function types from=20
=E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t *, v=
oid *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   pp_sys.c: In function =E2=80=98Perl_pp_system=E2=80=99:
   pp_sys.c:4421:28: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   embed.h:1400:55: note: in definition of macro =E2=80=98rsignal_save=E2=
=80=99
   pp_sys.c:4422:28: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
   miniperlmain.c: In function =E2=80=98main=E2=80=99:
   miniperlmain.c:139:29: warning: cast between incompatible function=20
types from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  sig=
info_t *, void *)=E2=80=99 {aka=20
=E2=80=98void (*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-typ=
e]
   perlmain.c: In function =E2=80=98main=E2=80=99:
   perlmain.c:133:29: warning: cast between incompatible function types=20
from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int,  siginfo_t=
 *, void *)=E2=80=99 {aka =E2=80=98void=20
(*)(int,  struct  *, void *)=E2=80=99} [-Wcast-function-type]
>=20
> commit 381ed9365524b3f482f2a06f8ee89d60d2f147c9
> Author:     David Mitchell <davem@iabyn.com>
> AuthorDate: Thu Oct 17 13:42:55 2019 +0100
> Commit:     David Mitchell <davem@iabyn.com>
> CommitDate: Mon Nov 4 11:23:51 2019 +0000
>=20
>      Rationalise perl's OS-level signal handler
>     =20
>      First some background:
>     =20
>      UNIXy OSes support two type of signal handler function:
>     =20
>      Signal_t handler1(int sig);
>      Signal_t handler3(int sig, siginfo_t *info, void *uap);
>     =20
>      The original one-argument handler was set using the signal(2) syst=
em
>      call. The newer sigaction(2) system call allows either a 1-arg or
>      3-arg handler to be specified:
>     =20
>          act.sa_handler =3D handler1;
>          sigaction(sig, act, NULL);
>     =20
>          act.sa_sigaction =3D handler3;
>          act.sa_sa_flags |=3D SA_SIGINFO;
>          sigaction(sig, act, NULL);
>     =20
>      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 wh=
enever
>      the kernel calls the handler, args 2 and 3 are whatever garbage th=
e OS
>      and architecture cause them to happen to be. Furthermore, some cod=
e in
>      the handler uses the nullness of args 2 and 3 to decide whether it=
 has
>      been called by the kernel, or explicitly as handler(sig,NULL,NULL)=
..
>      The fact that this condition works has just been down to luck so f=
ar.
>     =20
>      Note that POSIX.xs does allow a 3-arg signal handler to be specifi=
ed by
>      passing the SA_SIGINFO flag, and a couple of tests check for this.
>     =20
>      Recently, gcc-8 has been (quite reasonably) warning that we're pas=
sing
>      around 3-arg function pointers where a 1-arg function pointer is
>      expected.
>     =20
>      This commit does the following:
>     =20
>      1) It adds a new function, Perl_perly_sighandler() which is just
>      responsible for calling the perl-level $SIG{FOO} handler sub. This=
 new
>      function may either be called directly by Perl_csighandler (for un=
safe
>      signals), or called later by Perl_despatch_signals() for the more
>      normal safe signal regime. It has the 3 sig handler args, plus a f=
ourth
>      boolean arg which indicates whether it is being called in safe mod=
e.
>     =20
>      2) It adds explicit 1-arg and 3-arg variants of the C-level signal
>      handler functions sighandler1() and sigghandler3(), while the exis=
ting
>      function sighandler() has a signature which depends on the value o=
f
>      PERL_USE_3ARG_SIGHANDLER.
>     =20
> `    3) It disables PERL_USE_3ARG_SIGHANDLER by default. This means tha=
t
>      declarations such as Sighandler_t are now 1-arg to match the fact =
that
>      perl core is (as before) actually using a 1-arg handler most of th=
e
>      time.
>     =20
>      This commit isn't a complete fix: in particular using 3-arg handle=
rs by
>      default by enabling PERL_USE_3ARG_SIGHANDLER doesn't yet pass all =
tests.
>      That is left as an exercise to the reader.
>     =20
>      In summary, perl continues to use 1-arg signal handlers, but now
>      declares its handlers as 1-arg rather than 3-arg, so a bunch of co=
mpiler
>      warnings go away. Also, the code is now more rational and better
>      commented, so that moving to 3-arg handlers in the future won't be=
 so
>      hard.
>=20
>=20
0
public
11/6/2019 4:37:05 PM
On Wed, Nov 06, 2019 at 09:37:05AM -0700, Karl Williamson wrote:
> On 11/4/19 4:59 AM, Dave Mitchell wrote:
> > I've just pushed the following commit (smoke-me/davem/sighandler) for
> > smoking and possible discussion. I'd especially like feedback for
> > non-POSIX platforms: I have no idea whether this commit breaks signals on
> > those platforms.
> > 
> > (No idea whether I should be making this into a PR or something).
> 
> I see these warnings in an SuSE smoke from Tux

Is this from blead or my smoke-me branch?
> 
>   embed.h:474:44: note: in definition of macro ‘rsignal’
>   util.c: In function ‘Perl_rsignal’:
>   util.c:2716:22: warning: cast between incompatible function types from
> ‘Sighandler_t’ {aka ‘void (*)(int,  struct  *, void *)’} to ‘void (*)(int)’
> [-Wcast-function-type]

-- 
If life gives you lemons, you'll probably develop a citric acid allergy.
0
davem
11/6/2019 4:48:42 PM
On 11/6/19 9:48 AM, Dave Mitchell wrote:
> On Wed, Nov 06, 2019 at 09:37:05AM -0700, Karl Williamson wrote:
>> On 11/4/19 4:59 AM, Dave Mitchell wrote:
>>> I've just pushed the following commit (smoke-me/davem/sighandler) for
>>> smoking and possible discussion. I'd especially like feedback for
>>> non-POSIX platforms: I have no idea whether this commit breaks signal=
s on
>>> those platforms.
>>>
>>> (No idea whether I should be making this into a PR or something).
>>
>> I see these warnings in an SuSE smoke from Tux
>=20
> Is this from blead or my smoke-me branch?

Oh dear.  I wasn't thinking.  It is from blead, and I'm sorry for the noi=
se.

>>
>>    embed.h:474:44: note: in definition of macro =E2=80=98rsignal=E2=80=
=99
>>    util.c: In function =E2=80=98Perl_rsignal=E2=80=99:
>>    util.c:2716:22: warning: cast between incompatible function types f=
rom
>> =E2=80=98Sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int,  struct  *,=
 void *)=E2=80=99} to =E2=80=98void (*)(int)=E2=80=99
>> [-Wcast-function-type]
>=20
0
public
11/6/2019 4:55:28 PM
--Sig_/SRjTlTT=MXJsi3EQ2wuggy0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 6 Nov 2019 16:48:42 +0000, Dave Mitchell <davem@iabyn.com>
wrote:

> On Wed, Nov 06, 2019 at 09:37:05AM -0700, Karl Williamson wrote:
> > On 11/4/19 4:59 AM, Dave Mitchell wrote: =20
> > > I've just pushed the following commit (smoke-me/davem/sighandler)
> > > for smoking and possible discussion. I'd especially like feedback
> > > for non-POSIX platforms: I have no idea whether this commit
> > > breaks signals on those platforms.
> > >=20
> > > (No idea whether I should be making this into a PR or something).
> > > =20
> >=20
> > I see these warnings in an SuSE smoke from Tux =20
>=20
> Is this from blead or my smoke-me branch?

/me only smokes blead, so no smoke-me branches involved

> >   embed.h:474:44: note: in definition of macro =E2=80=98rsignal=E2=80=99
> >   util.c: In function =E2=80=98Perl_rsignal=E2=80=99:
> >   util.c:2716:22: warning: cast between incompatible function types
> > from =E2=80=98Sighandler_t=E2=80=99 {aka =E2=80=98void (*)(int,  struct=
  *, void *)=E2=80=99} to
> > =E2=80=98void (*)(int)=E2=80=99 [-Wcast-function-type] =20

--=20
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.31      porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email  https://tux.nl  http://www.test-smoke.org
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

--Sig_/SRjTlTT=MXJsi3EQ2wuggy0
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEGolmczWuFi3lJEbAA6FHoT5dwJgFAl3C+zUACgkQA6FHoT5d
wJgUAwf/cd2FeuuZq5qzPGQG9IlhrDq/TIiYodqLH1sxxWGCasQnMiXl0KUuzUUh
4Xt0/JX8+DMHQOyc8SHahSxTfdZLw9UVKG5I+WszWMoDmixVdVZ5H/bOK20TjGOn
LYdlfWVhxpvO51TzNtW/Wv+r72uk1A27xeoe9KgViRgHV/4vuvR/CW4yPuqCCLS+
cVpe1On0bhcsTHTBnm4fj8xmN8VGzrOgt3Vuc2TNifgfApSQqzsFYTSxSfvDuQtN
07vGossfbvzQxRaJP4NyruU82Cgb6EUmJKgr93jMkQZs8zLYtiW2la1Vwe3PvbP+
Sb3+N3jzCzMa9PE0iiB/iPXNBxVfBQ==
=OgKx
-----END PGP SIGNATURE-----

--Sig_/SRjTlTT=MXJsi3EQ2wuggy0--
0
h
11/6/2019 4:56:21 PM
On 11/4/19 6:54 PM, sisyphus wrote:
> Hi,
> The smoke-me/davem/sighandler branch didn't go at all well for me on 
> Windows 7, using mingw-w64 port of gcc-8.3.0.
> Running 'gmake' fails immediately 

Also fails on old dromedary's windows vm

 
         Microsoft (R) Program Maintenance Utility Version 
10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved. 
 
                        if not exist ".\mini" mkdir ".\mini" 

         copy config_H.vc config.h 
                 1 file(s) copied. 
                         cl -c -nologo -GF -W3 -MD -I..\lib\CORE 
-I.\include -I. -I.. -DWIN32 -D_
CONSOLE -DNO_STRICT -DDEBUGGING -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DPERLDLL -DPERL_CORE   -Od -Zi 
-DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\av.obj ..\av.c 

av.c 
        c:\users\p5p\khw\perl\working\iperlsys.h(54) : error C2143: 
syntax error : missing ')' before '*' 

c:\users\p5p\khw\perl\working\iperlsys.h(54) : error C2081: 'siginfo_t' 
: name in formal parameter list illegal 
                c:\users\p5p\khw\perl\working\iperlsys.h(54) : error 
C2143: syntax error : missi
ng '{' before '*' 

c:\users\p5p\khw\perl\working\iperlsys.h(54) : error C2059: syntax error 
: ','
c:\users\p5p\khw\perl\working\iperlsys.h(54) : error C2059: syntax error 
: ')'
c:\users\p5p\khw\perl\working\proto.h(706) : error C2143: syntax error : 
missc:\users\p5p\khw\perl\working\proto.h(706) : error C2081: 
'siginfo_t' : name in formal parameter list illegal 

c:\users\p5p\khw\perl\working\proto.h(706) : error C2143: syntax error : 
missing '{' before '*' 
               c:\users\p5p\khw\perl\working\proto.h(706) : error C2059: 
syntax error : 'type'
c:\users\p5p\khw\perl\working\proto.h(706) : error C2059: syntax error : 
')'    c:\users\p5p\khw\perl\working\proto.h(2651) : error C2143: syntax 
error : missing ')' before '*' 

c:\users\p5p\khw\perl\working\proto.h(2651) : error C2081: 'siginfo_t' : 
name in formal parameter list illegal 
               c:\users\p5p\khw\perl\working\proto.h(2651) : error 
C2143: syntax error : missing '{' before '*' 
 
c:\users\p5p\khw\perl\working\proto.h(2651) : error C2059: syntax error 
: 'type'c:\users\p5p\khw\perl\working\proto.h(2651) : error C2059: 
syntax error : ')'
c:\users\p5p\khw\perl\working\proto.h(3122) : error C2143: syntax error 
: missing ')' before '*' 
                c:\users\p5p\khw\perl\working\proto.h(3122) : error 
C2081: 'siginfo_t' : name in
  formal parameter list illegal 

c:\users\p5p\khw\perl\working\proto.h(3122) : error C2143: syntax error 
: missin
g '{' before '*' 

c:\users\p5p\khw\perl\working\proto.h(3122) : error C2059: syntax error 
: 'type'
c:\users\p5p\khw\perl\working\proto.h(3122) : error C2059: syntax error 
: ')'
c:\users\p5p\khw\perl\working\intrpvar.h(616) : error C2061: syntax 
error : iden
tifier 'PL_sighandler3p' 
        c:\users\p5p\khw\perl\working\intrpvar.h(616) : error C2059: 
syntax error : ';' c:\users\p5p\khw\perl\working\perlvars.h(82) : error 
C2061: syntax error : ident
ifier 'PL_csighandler3p' 
        c:\users\p5p\khw\perl\working\perlvars.h(82) : error C2059: 
syntax error : ';'  c:\users\p5p\khw\perl\working\intrpvar.h(616) : 
error C2061: syntax error : identifier 'Sighandler3_t' 
 
c:\users\p5p\khw\perl\working\perl.h(5540) : error C2059: syntax error : 
'}'    NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio 10.0\VC\BI
N\cl.EXE"' : return code '0x2' 
        Stop.
0
public
11/6/2019 11:45:13 PM
On Tue, Nov 05, 2019 at 12:54:54PM +1100, sisyphus wrote:
> Hi,
> The smoke-me/davem/sighandler branch didn't go at all well for me on
> Windows 7, using mingw-w64 port of gcc-8.3.0.

Here's a second branch: smoke-me/davem/sighandler2

Any better?

-- 
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
    -- Things That Never Happen in "Star Trek" #21
0
davem
11/12/2019 12:14:38 PM
On 11/12/19 5:14 AM, Dave Mitchell wrote:
> On Tue, Nov 05, 2019 at 12:54:54PM +1100, sisyphus wrote:
>> Hi,
>> The smoke-me/davem/sighandler branch didn't go at all well for me on
>> Windows 7, using mingw-w64 port of gcc-8.3.0.
> 
> Here's a second branch: smoke-me/davem/sighandler2
> 
> Any better?
> 

Worked for me on dromedary's windows.  It gave the typical results:


Test Summary Report 

------------------- 

.../cpan/IPC-Cmd/t/01_IPC-Cmd.t                                   (Wstat: 
768 Tes
ts: 459 Failed: 3) 

   Failed tests:  109, 115-116 

   Non-zero exit status: 3 

.../ext/IPC-Open3/t/IPC-Open3.t                                   (Wstat: 
0 Tests
: 45 Failed: 0) 

   TODO passed:   25 

Files=2664, Tests=1135805, 4828 wallclock secs (360.27 usr + 19.13 sys = 
379.39
CPU) 

Result: FAIL 
0
public
11/12/2019 11:02:45 PM
--0000000000004acfc5059732123b
Content-Type: text/plain; charset="UTF-8"

Yep - smoke-me/davem/sighandler2 is fine.

Test Summary Report
-------------------
.../cpan/IO-Compress/t/105oneshot-gzip.t                          (Wstat:
256 Tests: 176 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 1007 tests but ran 176.
.../ext/IPC-Open3/t/IPC-Open3.t                                   (Wstat: 0
Tests: 45 Failed: 0)
  TODO passed:   25
Files=2664, Tests=1137879, 1941 wallclock secs (66.10 usr +  4.10 sys =
70.20 CPU)
Result: FAIL

cpan/IO-Compress/t/105oneshot-gzip.t has decided to start hanging again
during 'make test', so I killed it to enable the test suite to proceed.
This is something that I've seen before, though not for a while.
It passes when run outside of the Test::Harness.

The same thing is happening in the blead branch, and this issue is
therefore NOT attributable to code specific to smoke-me/davem/sighandler2.

Cheers,
Rob

On Tue, Nov 12, 2019 at 11:14 PM Dave Mitchell <davem@iabyn.com> wrote:

> On Tue, Nov 05, 2019 at 12:54:54PM +1100, sisyphus wrote:
> > Hi,
> > The smoke-me/davem/sighandler branch didn't go at all well for me on
> > Windows 7, using mingw-w64 port of gcc-8.3.0.
>
> Here's a second branch: smoke-me/davem/sighandler2
>
> Any better?
>
> --
> The Enterprise's efficient long-range scanners detect a temporal vortex
> distortion in good time, allowing it to be safely avoided via a minor
> course correction.
>     -- Things That Never Happen in "Star Trek" #21
>

--0000000000004acfc5059732123b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yep - smoke-me/davem/sighandler2 is fine.</div><div><=
br>Test Summary Report<br>-------------------<br>../cpan/IO-Compress/t/105o=
neshot-gzip.t =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Wstat: 256 Tests: 176 Failed: 0)<br>=C2=A0 =
Non-zero exit status: 1<br>=C2=A0 Parse errors: Bad plan.=C2=A0 You planned=
 1007 tests but ran 176.<br>../ext/IPC-Open3/t/IPC-Open3.t =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Wstat: 0 Tests: 45 Failed: 0)<br>=C2=A0 TO=
DO passed: =C2=A0 25<br>Files=3D2664, Tests=3D1137879, 1941 wallclock secs =
(66.10 usr + =C2=A04.10 sys =3D 70.20 CPU)<br>Result: FAIL<br></div><div><b=
r></div><div>cpan/IO-Compress/t/105oneshot-gzip.t has decided to start hang=
ing again during &#39;make test&#39;, so I killed it to enable the test sui=
te to proceed.</div><div>This is something that I&#39;ve seen before, thoug=
h not for a while.</div><div>It passes when run outside of the Test::Harnes=
s.</div><div><br></div><div>The same thing is happening in the blead branch=
, and this issue is therefore NOT attributable to code specific to smoke-me=
/davem/sighandler2.</div><div><br></div><div>Cheers,</div><div>Rob<br></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Tue, Nov 12, 2019 at 11:14 PM Dave Mitchell &lt;<a href=3D"mailto:davem=
@iabyn.com">davem@iabyn.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">On Tue, Nov 05, 2019 at 12:54:54PM +1100, sisyph=
us wrote:<br>
&gt; Hi,<br>
&gt; The smoke-me/davem/sighandler branch didn&#39;t go at all well for me =
on<br>
&gt; Windows 7, using mingw-w64 port of gcc-8.3.0.<br>
<br>
Here&#39;s a second branch: smoke-me/davem/sighandler2<br>
<br>
Any better?<br>
<br>
-- <br>
The Enterprise&#39;s efficient long-range scanners detect a temporal vortex=
<br>
distortion in good time, allowing it to be safely avoided via a minor<br>
course correction.<br>
=C2=A0 =C2=A0 -- Things That Never Happen in &quot;Star Trek&quot; #21<br>
</blockquote></div>

--0000000000004acfc5059732123b--
0
sisyphus359
11/13/2019 3:36:16 AM
Reply: