perl.perl5.porters https://www.nntp.perl.org/group/perl.perl5.porters/ ... Copyright 1998-2018 perl.org Fri, 23 Feb 2018 00:26:42 +0000 ask@perl.org [perl #132879] commit "Add API function Perl_langinfo()" breaksXS-APItest/t/locale.t:ALT_DIGITS test by Karl Williamson via RT OP agrees that this is fixed<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132879<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249613.html Fri, 23 Feb 2018 00:12:57 +0000 Re: [perl #132900] Blead Breaks CPAN: FELIPE/Crypt-Perl-0.17.tar.gz by Zefram The failing dep isn&#39;t used by the failing test, so it&#39;s not too difficult<br/>to explore the intermediate versions. The test passes on 5.27.8.<br/>The problem bisects to commit ab1efbdc1f74b2f4db076efa0b4d54f387d74efe<br/>&quot;regexec.c: Use word-at-a-time to repeat a single byte pattern&quot;.<br/>The test case reduces to<br/><br/>$ perl5.27.8 -lwe &#39;print +(&quot;\x80&quot; x 9) =~ m&lt;\A\x80+\z&gt; ? &quot;yes&quot; : &quot;no&quot;&#39;<br/>yes<br/>$ perl5.27.9 -lwe &#39;print +(&quot;\x80&quot; x 9) =~ m&lt;\A\x80+\z&gt; ? &quot;yes&quot; : &quot;no&quot;&#39;<br/>no<br/><br/>Clearly a newly-introduced core bug.<br/><br/>-zefram<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249612.html Fri, 23 Feb 2018 00:11:51 +0000 [perl #132745] Langinfo.t fails on FreeBSD 9.2 by Karl Williamson via RT OP agrees that this has been fixed.<br/><br/>It happened somewhere in the large batch of locale-related commits since the bug was reported; not bothering to determine which<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132745<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249611.html Thu, 22 Feb 2018 23:38:56 +0000 [perl #132879] commit "Add API function Perl_langinfo()" breaksXS-APItest/t/locale.t:ALT_DIGITS test by bulk88 via RT On Thu, 22 Feb 2018 13:29:42 -0800, khw wrote:<br/>&gt; I believe a565fc6878252f7bedac409aee27aeb3fb9d7920 fixes this problem.<br/>&gt; Please verify.<br/><br/>its fixed<br/><br/><br/>-- <br/>bulk88 ~ bulk88 at hotmail.com<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132879<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249610.html Thu, 22 Feb 2018 23:34:00 +0000 [perl #132745] Langinfo.t fails on FreeBSD 9.2 by slaven@rezic.de via RT Dana Thu, 22 Feb 2018 14:07:55 -0800, khw re&Auml;&#141;e:<br/>&gt; I think this has been fixed in blead. Could you please verify?<br/><br/>Confirmed. 5.27.9 tests run without problems.<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132745<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249609.html Thu, 22 Feb 2018 23:12:11 +0000 Re: [perl #132561] miniperl segfault on blead (duplocale /S_my_nl_langinfo) by Tony Cook On Thu, Feb 22, 2018 at 03:52:16PM -0700, Karl Williamson wrote:<br/>&gt; On 02/22/2018 03:18 PM, Karl Williamson wrote:<br/>&gt; &gt; On 02/22/2018 02:59 PM, Tony Cook wrote:<br/>&gt; &gt; &gt; On Thu, Feb 22, 2018 at 01:42:24PM -0800, Karl Williamson via RT wrote:<br/>&gt; &gt; &gt; &gt; So, this should have a hints file change for Linux, that says<br/>&gt; &gt; &gt; &gt; certain earlier versions should not use the Posix 2008<br/>&gt; &gt; &gt; &gt; functions, even if they are present.&nbsp; This is because they&#39;ve<br/>&gt; &gt; &gt; &gt; been found to be buggy.<br/>&gt; &gt; &gt; &gt; <br/>&gt; &gt; &gt; &gt; The problem is I don&#39;t know what the cut-off version should be.&nbsp;<br/>&gt; &gt; &gt; &gt; I know it works on 4.10, and it doesn&#39;t work on 2.6.24.&nbsp; But<br/>&gt; &gt; &gt; &gt; what should the hints file use?&nbsp; Suggestions for how to<br/>&gt; &gt; &gt; &gt; determine this are welcome. Or, if you have an example of it<br/>&gt; &gt; &gt; &gt; working on an earlier version than 4.10, post it, so that we can<br/>&gt; &gt; &gt; &gt; narrow it down.<br/>&gt; &gt; &gt; &gt; <br/>&gt; &gt; &gt; &gt; Given that there is no further reports of failure, I&#39;m presuming<br/>&gt; &gt; &gt; &gt; nobody has an example of it failing after 2.6.24, and so I&#39;m<br/>&gt; &gt; &gt; &gt; tempted to make that the cut-off, unless further information<br/>&gt; &gt; &gt; &gt; and/or suggestions are received<br/>&gt; &gt; &gt; <br/>&gt; &gt; &gt; It&#39;s more likely to depend on the glibc version than the kernel<br/>&gt; &gt; &gt; version.<br/>&gt; &gt; &gt; <br/>&gt; &gt; &gt; Also, some Linux distributions use an alternate libc.<br/>&gt; &gt; &gt; <br/>&gt; &gt; &gt; Tony<br/>&gt; &gt; &gt; <br/>&gt; &gt; <br/>&gt; &gt; <br/>&gt; &gt; Good points.<br/>&gt; &gt; <br/>&gt; &gt; However, the output in this ticket says that bram is using<br/>&gt; &gt; <br/>&gt; &gt; gnulibc_version=&#39;2.7&#39;<br/>&gt; &gt; <br/>&gt; &gt; and that is failing; whereas I&#39;m using<br/>&gt; &gt; <br/>&gt; &gt; gnulibc_version=&#39;2.24&#39; on a much later Linux<br/>&gt; &gt; <br/>&gt; &gt; and it is working.&nbsp; I don&#39;t understand.<br/>&gt; &gt; <br/>&gt; <br/>&gt; I misread my version as 2.4; not 2.24, so it does make sense. Anyway does<br/>&gt; anyone have an earlier version of glibc where it does work than 2.24?<br/><br/>https://sourceware.org/bugzilla/show_bug.cgi?id=10969<br/><br/>Apparently fixed in 2.12:<br/><br/>https://github.com/lattera/glibc/blob/master/NEWS<br/><br/>Tony<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249608.html Thu, 22 Feb 2018 23:07:45 +0000 Re: [perl #132561] miniperl segfault on blead (duplocale /S_my_nl_langinfo) by Karl Williamson On 02/22/2018 03:18 PM, Karl Williamson wrote: <br/>&gt; On 02/22/2018 02:59 PM, Tony Cook wrote: <br/>&gt;&gt; On Thu, Feb 22, 2018 at 01:42:24PM -0800, Karl Williamson via RT wrote: <br/>&gt;&gt;&gt; So, this should have a hints file change for Linux, that says certain <br/>&gt;&gt;&gt; earlier versions should not use the Posix 2008 functions, even if <br/>&gt;&gt;&gt; they are present.&nbsp; This is because they&#39;ve been found to be buggy. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; The problem is I don&#39;t know what the cut-off version should be.&nbsp; I <br/>&gt;&gt;&gt; know it works on 4.10, and it doesn&#39;t work on 2.6.24.&nbsp; But what <br/>&gt;&gt;&gt; should the hints file use?&nbsp; Suggestions for how to determine this are <br/>&gt;&gt;&gt; welcome. Or, if you have an example of it working on an earlier <br/>&gt;&gt;&gt; version than 4.10, post it, so that we can narrow it down. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Given that there is no further reports of failure, I&#39;m presuming <br/>&gt;&gt;&gt; nobody has an example of it failing after 2.6.24, and so I&#39;m tempted <br/>&gt;&gt;&gt; to make that the cut-off, unless further information and/or <br/>&gt;&gt;&gt; suggestions are received <br/>&gt;&gt; <br/>&gt;&gt; It&#39;s more likely to depend on the glibc version than the kernel <br/>&gt;&gt; version. <br/>&gt;&gt; <br/>&gt;&gt; Also, some Linux distributions use an alternate libc. <br/>&gt;&gt; <br/>&gt;&gt; Tony <br/>&gt;&gt; <br/>&gt; <br/>&gt; <br/>&gt; Good points. <br/>&gt; <br/>&gt; However, the output in this ticket says that bram is using <br/>&gt; <br/>&gt; gnulibc_version=&#39;2.7&#39; <br/>&gt; <br/>&gt; and that is failing; whereas I&#39;m using <br/>&gt; <br/>&gt; gnulibc_version=&#39;2.24&#39; on a much later Linux <br/>&gt; <br/>&gt; and it is working.&nbsp; I don&#39;t understand. <br/>&gt; <br/> <br/>I misread my version as 2.4; not 2.24, so it does make sense. Anyway <br/>does anyone have an earlier version of glibc where it does work than 2.24? <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249607.html Thu, 22 Feb 2018 22:52:33 +0000 [perl #132900] Blead Breaks CPAN: FELIPE/Crypt-Perl-0.17.tar.gz by slaven @ rezic . de # New Ticket Created by slaven@rezic.de <br/># Please include the string: [perl #132900]<br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=132900 &gt;<br/><br/><br/><br/>This is a bug report for perl from slaven@rezic.de,<br/>generated with the help of perlbug 1.41 running under perl 5.27.9.<br/><br/><br/>-----------------------------------------------------------------<br/>The t/Crypt-Perl-RSA-PrivateKey.t in Crypt-Perl-0.17 fails with<br/>perl 5.27.9 (and also 5.27.8-157-gef80cd9). The last released perl<br/>with passes was perl 5.27.5 (and it passes also with<br/>5.27.5-170-ga385812b68). There are no results in between because of<br/>dependency build problems.<br/><br/>Sample reports:<br/>http://fast-matrix.cpantesters.org/?dist=Crypt-Perl%200.17;perl=5.27.9;reports=1<br/><br/>-----------------------------------------------------------------<br/>---<br/>Flags:<br/> category=core<br/> severity=low<br/>---<br/>Site configuration information for perl 5.27.9:<br/><br/>Configured by eserte at Tue Feb 20 21:59:42 CET 2018.<br/><br/>Summary of my perl5 (revision 5 version 27 subversion 9) configuration:<br/> <br/> Platform:<br/> osname=linux<br/> osvers=3.16.0-4-amd64<br/> archname=x86_64-linux<br/> uname=&#39;linux cabulja 3.16.0-4-amd64 #1 smp debian 3.16.51-3 (2017-12-13) x86_64 gnulinux &#39;<br/> config_args=&#39;-ds -e -Dprefix=/opt/perl-5.27.9 -Dusedevel -Dusemallocwrap=no -Dcf_email=srezic@cpan.org&#39;<br/> hint=recommended<br/> useposix=true<br/> d_sigaction=define<br/> useithreads=undef<br/> usemultiplicity=undef<br/> use64bitint=define<br/> use64bitall=define<br/> uselongdouble=undef<br/> usemymalloc=n<br/> default_inc_excludes_dot=define<br/> bincompat5005=undef<br/> Compiler:<br/> cc=&#39;cc&#39;<br/> ccflags =&#39;-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2&#39;<br/> optimize=&#39;-O2&#39;<br/> cppflags=&#39;-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include&#39;<br/> ccversion=&#39;&#39;<br/> gccversion=&#39;4.9.2&#39;<br/> gccosandvers=&#39;&#39;<br/> intsize=4<br/> longsize=8<br/> ptrsize=8<br/> doublesize=8<br/> byteorder=12345678<br/> doublekind=3<br/> d_longlong=define<br/> longlongsize=8<br/> d_longdbl=define<br/> longdblsize=16<br/> longdblkind=3<br/> ivtype=&#39;long&#39;<br/> ivsize=8<br/> nvtype=&#39;double&#39;<br/> nvsize=8<br/> Off_t=&#39;off_t&#39;<br/> lseeksize=8<br/> alignbytes=8<br/> prototype=define<br/> Linker and Libraries:<br/> ld=&#39;cc&#39;<br/> ldflags =&#39; -fstack-protector-strong -L/usr/local/lib&#39;<br/> libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib<br/> libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat<br/> perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc<br/> libc=libc-2.19.so<br/> so=so<br/> useshrplib=false<br/> libperl=libperl.a<br/> gnulibc_version=&#39;2.19&#39;<br/> Dynamic Linking:<br/> dlsrc=dl_dlopen.xs<br/> dlext=so<br/> d_dlsymun=undef<br/> ccdlflags=&#39;-Wl,-E&#39;<br/> cccdlflags=&#39;-fPIC&#39;<br/> lddlflags=&#39;-shared -O2 -L/usr/local/lib -fstack-protector-strong&#39;<br/><br/><br/>---<br/>@INC for perl 5.27.9:<br/> /opt/perl-5.27.9/lib/site_perl/5.27.9/x86_64-linux<br/> /opt/perl-5.27.9/lib/site_perl/5.27.9<br/> /opt/perl-5.27.9/lib/5.27.9/x86_64-linux<br/> /opt/perl-5.27.9/lib/5.27.9<br/><br/>---<br/>Environment for perl 5.27.9:<br/> HOME=/home/eserte<br/> LANG=en_US.UTF-8<br/> LANGUAGE (unset)<br/> LD_LIBRARY_PATH (unset)<br/> LOGDIR (unset)<br/> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/eserte/bin/linux-gnu:/home/eserte/bin/sh:/home/eserte/bin:/home/eserte/bin/pistachio-perl/bin:/usr/games:/home/eserte/devel<br/> PERLDOC=-MPod::Perldoc::ToTextOverstrike<br/> PERL_BADLANG (unset)<br/> SHELL=/bin/zsh<br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249606.html Thu, 22 Feb 2018 22:30:38 +0000 Re: [perl #132561] miniperl segfault on blead (duplocale /S_my_nl_langinfo) by Karl Williamson On 02/22/2018 02:59 PM, Tony Cook wrote:<br/>&gt; On Thu, Feb 22, 2018 at 01:42:24PM -0800, Karl Williamson via RT wrote:<br/>&gt;&gt; So, this should have a hints file change for Linux, that says certain earlier versions should not use the Posix 2008 functions, even if they are present. This is because they&#39;ve been found to be buggy.<br/>&gt;&gt;<br/>&gt;&gt; The problem is I don&#39;t know what the cut-off version should be. I know it works on 4.10, and it doesn&#39;t work on 2.6.24. But what should the hints file use? Suggestions for how to determine this are welcome. Or, if you have an example of it working on an earlier version than 4.10, post it, so that we can narrow it down.<br/>&gt;&gt;<br/>&gt;&gt; Given that there is no further reports of failure, I&#39;m presuming nobody has an example of it failing after 2.6.24, and so I&#39;m tempted to make that the cut-off, unless further information and/or suggestions are received<br/>&gt; <br/>&gt; It&#39;s more likely to depend on the glibc version than the kernel<br/>&gt; version.<br/>&gt; <br/>&gt; Also, some Linux distributions use an alternate libc.<br/>&gt; <br/>&gt; Tony<br/>&gt; <br/><br/><br/>Good points.<br/><br/>However, the output in this ticket says that bram is using<br/><br/>gnulibc_version=&#39;2.7&#39;<br/><br/>and that is failing; whereas I&#39;m using<br/><br/>gnulibc_version=&#39;2.24&#39; on a much later Linux<br/><br/>and it is working. I don&#39;t understand.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249605.html Thu, 22 Feb 2018 22:19:05 +0000 [perl #132745] Langinfo.t fails on FreeBSD 9.2 by Karl Williamson via RT I think this has been fixed in blead. Could you please verify?<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132745<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249604.html Thu, 22 Feb 2018 22:08:10 +0000 Re: [perl #132561] miniperl segfault on blead (duplocale /S_my_nl_langinfo) by Tony Cook On Thu, Feb 22, 2018 at 01:42:24PM -0800, Karl Williamson via RT wrote:<br/>&gt; So, this should have a hints file change for Linux, that says certain earlier versions should not use the Posix 2008 functions, even if they are present. This is because they&#39;ve been found to be buggy.<br/>&gt; <br/>&gt; The problem is I don&#39;t know what the cut-off version should be. I know it works on 4.10, and it doesn&#39;t work on 2.6.24. But what should the hints file use? Suggestions for how to determine this are welcome. Or, if you have an example of it working on an earlier version than 4.10, post it, so that we can narrow it down.<br/>&gt; <br/>&gt; Given that there is no further reports of failure, I&#39;m presuming nobody has an example of it failing after 2.6.24, and so I&#39;m tempted to make that the cut-off, unless further information and/or suggestions are received<br/><br/>It&#39;s more likely to depend on the glibc version than the kernel<br/>version.<br/><br/>Also, some Linux distributions use an alternate libc.<br/><br/>Tony<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249603.html Thu, 22 Feb 2018 21:59:39 +0000 [perl #132561] miniperl segfault on blead (duplocale /S_my_nl_langinfo) by Karl Williamson via RT So, this should have a hints file change for Linux, that says certain earlier versions should not use the Posix 2008 functions, even if they are present. This is because they&#39;ve been found to be buggy.<br/><br/>The problem is I don&#39;t know what the cut-off version should be. I know it works on 4.10, and it doesn&#39;t work on 2.6.24. But what should the hints file use? Suggestions for how to determine this are welcome. Or, if you have an example of it working on an earlier version than 4.10, post it, so that we can narrow it down.<br/><br/>Given that there is no further reports of failure, I&#39;m presuming nobody has an example of it failing after 2.6.24, and so I&#39;m tempted to make that the cut-off, unless further information and/or suggestions are received<br/><br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132561<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249602.html Thu, 22 Feb 2018 21:42:35 +0000 [perl #132879] commit "Add API function Perl_langinfo()" breaksXS-APItest/t/locale.t:ALT_DIGITS test by Karl Williamson via RT I believe a565fc6878252f7bedac409aee27aeb3fb9d7920 fixes this problem. Please verify.<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132879<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249601.html Thu, 22 Feb 2018 21:29:45 +0000 Is there a reason not to add '$| = 1" to t/test.pl by Karl Williamson When looking at test failures, it&#39;s nice to have the failure output <br/>adjacent to the actual test that fails. And, I&#39;ve added this to many of <br/>the .t files I&#39;ve changed, but is there a reason not to make it part of <br/>standard t/test.pl?<br/><br/>If it&#39;s because of the low level base directory tests shouldn&#39;t have <br/>this complication added to them, we could skip doing this for tests in <br/>that directory.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249600.html Thu, 22 Feb 2018 21:15:38 +0000 [perl #132899] MakeMaker 7.32 breaks darwin by Sergey Aleynikov via RT On Thu, 22 Feb 2018 12:17:29 -0800, public@khwilliamson.com wrote:<br/>&gt; Darwin has been failing since<br/><br/>I&#39;ve reported this 4 days ago to EU::MM - https://rt.cpan.org/Ticket/Display.html?id=124465<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132899<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249599.html Thu, 22 Feb 2018 20:42:25 +0000 [perl #132899] MakeMaker 7.32 breaks darwin by karl williamson # New Ticket Created by karl williamson <br/># Please include the string: [perl #132899]<br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=132899 &gt;<br/><br/><br/>Darwin has been failing since<br/><br/>commit 09a7143acf21dfa32d1eb4baef619ceb18c46d1f<br/> Author: Chris &#39;BinGOs&#39; Williams &lt;chris@bingosnet.co.uk&gt;<br/> Date: Sat Feb 17 10:42:32 2018 +0000<br/><br/> Update ExtUtils-MakeMaker to CPAN version 7.32<br/><br/>Sample fail report:<br/><br/>http://perl.develop-help.com/raw/?id=206715<br/><br/>I verified that this was the commit where the failures started<br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249598.html Thu, 22 Feb 2018 20:18:58 +0000 Re: [perl #132894] Blead Breaks CPAN:MAROS/DateTime-Format-CLDR-1.19.tar.gz by Zefram The Perl version difference that I see between 5.21.3 and<br/>5.21.4 (on Linux with nvtype=long double) bisects to commit<br/>8a00eddcbace6ea4d95ca7780e8ec310ce6feb88 &quot;POSIX math: have the Perl_func<br/>wrappers for the C89 math, too.&quot;, which changes some POSIX functions<br/>to use the long-double versions of C functions on long-double builds.<br/>This goes some way to explaining the nvtype difference that I see on<br/>older perls. It also hints that the OS difference that Slaven sees<br/>might be due to libc differences in these math functions.<br/><br/>The perl version differences that I see on older perls (on Linux<br/>with nvtype=double) still look likely to be due to module versions.<br/>There&#39;s clearly more than one factor at work.<br/><br/>-zefram<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249597.html Thu, 22 Feb 2018 19:23:19 +0000 Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz by Zefram Peter Rabbitson wrote:<br/>&gt;The above statement is false.<br/><br/>It still seems true to me. Perhaps you could explicate what other<br/>advantage the dual-location proposal has, relative to having signatures<br/>after all attributes.<br/><br/>&gt;Zefram&#39;s argument over the past several months is predicated on the idea that<br/>&gt;signatures never existed in a stable form within the Perl5 ecosystem, and<br/>&gt;didn&#39;t exist at all before 5.22.<br/>&gt;<br/>&gt;That idea is false (at best)<br/><br/>My argument is in no way predicated on signatures not having existed<br/>before 5.22. The idea that they didn&#39;t exist certainly is false,<br/>and I&#39;m acutely aware of it, due to my role in getting signatures into<br/>5.20 and in arguing against them being damaged into their 5.22 form.<br/>I am mystified as to how you come to think that I would entertain that<br/>patently false idea.<br/><br/>The idea that signatures have never been stable is true, unless you&#39;re<br/>playing games with the wording. The stable releases of Perl that have<br/>included signatures have all included explicit warnings, in documentation<br/>and at compile time, that signatures are experimental. They have thus<br/>never qualified as a stable feature, in our usual parlance. Perhaps you<br/>mean something else by &quot;stable&quot;, but in that case you&#39;ll have to explain<br/>what you mean in order to further your argument.<br/><br/>My argument doesn&#39;t entirely depend on the experimental status of<br/>signatures, though because they do have that status I have couched my<br/>argument in that context. Preceding attributes is the wrong place for<br/>signatures regardless of stability. Signatures are also much newer<br/>than attributes (and the :lvalue attribute in particular) and tacitly<br/>more experimental, regardless of formal status. The relevance of the<br/>formal stability status is only to provide a big explicit bias in the<br/>coherence vs stability tradeoff with which we are faced. It would still<br/>be reasonable to judge in favour of coherence without it.<br/><br/>-zefram<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249596.html Thu, 22 Feb 2018 17:19:03 +0000 CPAN-river-1000: failures as of perl-5.27.9 by James E Keenan You can find data from a test run of the &quot;CPAN-river-top-1000&quot; against <br/>perl-5.27.9 here:<br/><br/>http://thenceforward.net/perl/misc/cpan-river-1000-perl-5.27-master.psv.gz<br/><br/>The file above presents the data in the same format which I used for <br/>5.27.6 and 5.27.7 in November and December 2017. What is essentially <br/>the same data is presented in a slightly different format here:<br/><br/>http://thenceforward.net/perl/misc/xformat-cpan-river-1000-perl-5.27-master.psv.gz<br/><br/>The attachment, &#39;changes-5.27.8-to-5.27.9.csv&#39;, presents another subset <br/>of the data set found at the second link above. It presents results <br/>from just the last two monthly releases for those distributions which <br/>either (a) had a change of grade between 5.27.8 and 5.27.9; or (b) <br/>received a grade other than &#39;PASS&#39; in 5.27.9.<br/><br/>The number of entries in the changes-5.27.8-to-5.27.9.csv file is <br/>considerably smaller than the corresponding file posted last month after <br/>5.27.8 was released. This occurred primarily because several CPAN <br/>authors/maintainers brought their distributions into compliance with <br/>perl-5.28 expectations.<br/><br/>Anyone who wishes to follow up on this data or help me<br/>further develop analyses like this should contact me.<br/><br/>Thank you very much.<br/>Jim Keenan<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249595.html Thu, 22 Feb 2018 17:03:47 +0000 [perl #132897] timegm should be called with 4-digit year by James E Keenan via RT On Thu, 22 Feb 2018 10:17:25 GMT, perlbugbmw@lsmod.de wrote:<br/>&gt; <br/>&gt; This is a bug report for perl from perlbugbmw@lsmod.de,<br/>&gt; generated with the help of perlbug 1.39 running under perl 5.18.2.<br/>&gt; <br/>&gt; <br/>&gt; -----------------------------------------------------------------<br/>&gt; [Please describe your issue here]<br/>&gt; <br/>&gt; timegm should be called with 4-digit year<br/>&gt; to avoid ambiguities in Time::Local with 2-digit years<br/>&gt; that cause a bug in 2020<br/>&gt; <br/>&gt; note: while this is only documentation, I found that some people do<br/>&gt; RTFM<br/>&gt; and included this snippet in their module<br/>&gt; e.g. Parse-Win32Registry, HTTP-Cookies and HTTP-Message<br/>&gt; <br/>&gt; please review/test/merge this fix:<br/>&gt; <br/>&gt; --- perl-5.26.1.orig/pod/perlport.pod<br/>&gt; +++ perl-5.26.1/pod/perlport.pod<br/>&gt; @@ -673 +673 @@<br/>&gt; - my $offset = timegm(0, 0, 0, 1, 0, 70);<br/>&gt; + my $offset = timegm(0, 0, 0, 1, 0, 1970);<br/>&gt; <br/><br/>Pinging Dave Rolsky, upstream maintainer for Time::Local:<br/><br/>Dave, okay to make this change in &#39;perlport&#39;?<br/><br/>Thank you very much.<br/>Jim Keenan<br/><br/><br/>-- <br/>James E Keenan (jkeenan@cpan.org)<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132897<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249594.html Thu, 22 Feb 2018 14:58:40 +0000 [perl #132898] timegm should be called with 4-digit year by James E Keenan via RT libnet is maintained upstream on CPAN. I have opened this ticket in that distribution&#39;s bugtracker.<br/><br/>https://rt.cpan.org/Ticket/Display.html?id=124534<br/><br/>-- <br/>James E Keenan (jkeenan@cpan.org)<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132898<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249593.html Thu, 22 Feb 2018 14:44:55 +0000 [perl #132896] timegm should be called with 4-digit year by James E Keenan via RT libnet is maintained upstream on CPAN. I have opened this ticket in that distribution&#39;s bugtracker.<br/><br/>https://rt.cpan.org/Ticket/Display.html?id=124534<br/><br/>-- <br/>James E Keenan (jkeenan@cpan.org)<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132896<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249592.html Thu, 22 Feb 2018 14:43:31 +0000 Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz by demerphq On 22 Feb 2018 20:11, &quot;Peter Rabbitson&quot; &lt;rabbit-p5p@rabbit.us&gt; wrote:<br/><br/>On 02/21/2018 07:56 PM, Zefram wrote:<br/><br/>&gt; Relative to the present situation of having signatures after all<br/>&gt; attributes, the proposal for double helpings of attributes has only one<br/>&gt; advantage, namely compatibility with the 5.22-5.26 version of signatures.<br/>&gt;<br/><br/>The above statement is false.<br/><br/>Zefram&#39;s argument over the past several months is predicated on the idea<br/>that signatures never existed in a stable form within the Perl5 ecosystem,<br/>and didn&#39;t exist at all before 5.22.<br/><br/><br/>The above statement is at best a half truth. Not only that it is an<br/>unhelpful contribution to the discussion.<br/><br/>The key problem is that putting signatures before attributes means that the<br/>potential uses of attributes are severely limited, especially given the<br/>complexity we have allowed in the signature definition.<br/><br/>This point is utterly devastating to the counter-arguments that have been<br/>made. They all fall flat when this is taken into account.<br/><br/>The additional arguments about experimental status are merely icing on the<br/>cake, or perhaps better put as the final nails in the coffin.<br/><br/>If you have something more useful to contribute that accusing a key<br/>contributor of telling falsehoods then please do so, but the type of<br/>feedback provided here is unhelpful and imo unwelcome.<br/><br/>Thanks,<br/>Yved<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249591.html Thu, 22 Feb 2018 12:50:30 +0000 Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz by Peter Rabbitson On 02/21/2018 07:56 PM, Zefram wrote:<br/>&gt; Relative to the present situation of having signatures after all<br/>&gt; attributes, the proposal for double helpings of attributes has only one<br/>&gt; advantage, namely compatibility with the 5.22-5.26 version of signatures.<br/><br/>The above statement is false.<br/><br/>Zefram&#39;s argument over the past several months is predicated on the idea <br/>that signatures never existed in a stable form within the Perl5 <br/>ecosystem, and didn&#39;t exist at all before 5.22.<br/><br/>That idea is false (at best)<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249590.html Thu, 22 Feb 2018 12:11:30 +0000 Re: [perl #132892] Possibly memory leak when matching strings usingpre-compiled regexes stored in hash key (perl >= v5.26) by demerphq On 22 Feb 2018 12:39, &quot;via RT&quot; &lt;perlbug-followup@perl.org&gt; wrote: <br/> <br/># New Ticket Created by <br/># Please include the string: [perl #132892] <br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=132892 &gt; <br/> <br/> <br/>Hello guys, <br/> <br/>I have a long running perl script which allows the user configure the <br/>program behavior with a hash that got pre-compiled regexps <br/>as keys and the corresponding callback code as the value like below. <br/>Recently I have upgraded to perl v5.26 and the memory <br/>usage grows since then, so I have fall back to perl v5.24.3 as a temporary <br/>solution. What I observed before fallback is that the <br/>memory grows when I try to iterates the hash keys and matches them against <br/>some text. <br/> <br/>%action = ( <br/> <br/> qr/^regex here/ =&gt; sub { print &quot;match&quot; }, <br/> <br/>); <br/> <br/> <br/>Regardless if the bug, perl hash keys are strings not objects. Perl will <br/>compile these patterns, then stringify them to store them as keys, and then <br/>when used later will recompile again. You need a better data structure. <br/> <br/>Yves <br/> <br/> <br/> <br/>I have written a small test for this problem, you can find it in the <br/>attached perlbug.tar.xz. 20180221-mem-leak-poc.pl is the prof of <br/>concept code. It will output the platform and perl version as the first <br/>line, and make use of the ps command to retrieve the vsz and <br/>rss of the perl interpreter before each iteration. The test result of <br/>different platform are stored in the rslt/ sub-directory for your reference. <br/>According to the results, with perl &lt;v5.26, the size in memory remain <br/>unchanged; While the memory usage keeps increasing when the <br/>script is run with perl &gt;=v5.26. I have limited the number of iteration, <br/>the memory usage grows further if you increases the number of iteration. <br/> <br/>|-- 20180221-mem-leak-poc.pl <br/>`-- rslt <br/> |-- centos6-p5.10.1.log <br/> |-- centos6-p5.24.3.log <br/> |-- centos6-p5.26.1.log <br/> |-- centos6-p5.27.8.log <br/> |-- dfbsd-p5.24.3.log <br/> |-- dfbsd-p5.26.1.log <br/> |-- freebsd-p5.24.3.log <br/> `-- freebsd-p5.26.1.log <br/> <br/>According to my empirical result, this problem occurs when using perl newer <br/>than v5.26, the first line of perl -v of the affected perl <br/>interpreters below. <br/> <br/>&gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for amd64-freebsd <br/>&gt; This is perl 5, version 27, subversion 8 (v5.27.8) built for x86_64-linux <br/>&gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux <br/> <br/>This is perl 5, version 26, subversion 1 (v5.26.1) built for <br/>&gt; x86_64-dragonfly <br/> <br/> <br/>I have traced the problem a little bit and I *guess* the problem is in the <br/>function S_concat_pat of regcomp.c and the new SVs <br/>copied out are immortal, so every time my program iterate through the keys <br/>of hash to match against things, it creates more <br/>copies of the regexes. I can try to dig deeper when I am free to build the <br/>debug versions of perl, but that would be great if this <br/>case can be taken care by the professionals here. Thanks a lot. <br/>&acirc;&#128;&#139; <br/> <br/>&acirc;&#128;&#139; <br/>Best regards, <br/>Baggio <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249589.html Thu, 22 Feb 2018 11:51:03 +0000 [perl #132892] Possibly memory leak when matching strings usingpre-compiled regexes stored in hash key (perl >= v5.26) by Sergey Aleynikov via RT Bisect points to commit b10cb25a6c86fd96fff8f2dfa6d8df3e6b51a451<br/>Author: Yves Orton &lt;demerphq@gmail.com&gt;<br/>Date: Sat Sep 17 20:14:53 2016 +0200<br/><br/> regcomp.c: S_concat_pat: guard against missing trailing nulls<br/><br/> The regex engine expects the pattern to have a null byte at<br/> SvEND(pat), but is not guaranteed to receive such a pattern<br/> when it is called, so S_concat_pat should guard against this<br/> case. It turns out this is only an issue when there is exactly<br/> one &quot;argument&quot; to the pattern. (Consider concatenation rules, etc).<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132892<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249588.html Thu, 22 Feb 2018 11:30:23 +0000 Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz by Dave Mitchell On Wed, Feb 21, 2018 at 06:56:26PM +0000, Zefram wrote:<br/>&gt; Dave Mitchell wrote:<br/>&gt; &gt;The more I think about this, the more I think that attributes should<br/>&gt; &gt;be allowed in *either* position, with a warning or croak for specific<br/>&gt; &gt;attributes found in the &quot;wrong&quot; location:<br/>&gt; <br/>&gt; That would be a bad idea.<br/>[snip]<br/><br/>Ok, I&#39;m convinced (mostly).<br/><br/>I plan to do the following two things shortly (assuming they prove<br/>feasible):<br/><br/>1) change the parser so that subs under &#39;use feature signatures&#39; use<br/>a different grammar rule than subs not under it - possibly by making the<br/>toker return two different sub tokens, e.g. &#39;SUB&#39; and a new &#39;SIGSUB&#39;<br/>token say, depending on whether the feature is in scope.<br/><br/>This will then help reduce confusing errors, e.g. this code with a syntax<br/>error (attrs before prototype):<br/><br/> no feature &#39;signatures&#39;;<br/> sub f :lvalue ($$@) { $x = 1 }<br/><br/>currently gives:<br/><br/> Illegal character following sigil in a subroutine signature at<br/> ..., near &quot;($&quot;<br/><br/>It&#39;s parsing the ($$@) as a sub signature even though signatures aren&#39;t in<br/>scope, so the error message is confusing.<br/><br/>2) For the signature sub grammar rule, allow it to spot attributes<br/>following a signature and croak with a meaningful error. Which is what the<br/>OP requested.<br/><br/><br/>-- <br/>But Pity stayed his hand. &quot;It&#39;s a pity I&#39;ve run out of bullets&quot;,<br/>he thought. -- &quot;Bored of the Rings&quot;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249587.html Thu, 22 Feb 2018 10:27:29 +0000 Re: Zefram 2018-W07 TPF grant report by Shlomi Fish On Mon, 19 Feb 2018 06:48:11 +0000 <br/>Zefram &lt;zefram@fysh.org&gt; wrote: <br/> <br/>&gt; The hours that I have worked in 2018-W07 pursuant to my TPF core <br/>&gt; maintenance grant are as follows. <br/>&gt; <br/>&gt; 2018-02-12: <br/>&gt; No activity. <br/>&gt; <br/>&gt; 2018-02-13: <br/>&gt; No activity. <br/>&gt; <br/>&gt; 2018-02-14: <br/>&gt; No activity. <br/>&gt; <br/>&gt; 2018-02-15: <br/>&gt; 2h29m [perl #132833] COW bug in :encoding layer <br/>&gt; 36m [perl #132788] Blead Breaks CPAN: <br/>&gt; LEMBARK/Object-Trampoline-1.42.tar.gz <br/>&gt; 33m [perl #132760] Blead Breaks CPAN: <br/>&gt; YANICK/List-Lazy-0.3.0.tar.gz <br/>&gt; 12m review mail <br/>&gt; 3h50m TOTAL <br/>&gt; <br/>&gt; 2018-02-16: <br/>&gt; 56m review mail <br/>&gt; 42m [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz <br/>&gt; 39m [perl #132833] COW bug in :encoding layer <br/>&gt; 29m [perl #132873] Blead Breaks CPAN: JOHNH/Fsdb-2.64.tar.gz <br/>&gt; 2h46m TOTAL <br/>&gt; <br/>&gt; 2018-02-17: <br/>&gt; 45m PathTools version portability <br/>&gt; 10m review mail <br/>&gt; 55m TOTAL <br/>&gt; <br/>&gt; 2018-02-18: <br/>&gt; 32m review mail <br/>&gt; 20m [perl #7515] perlio bug ? <br/>&gt; 52m TOTAL <br/>&gt; <br/>&gt; 2018-W07 as a whole: <br/>&gt; 3h08m [perl #132833] COW bug in :encoding layer <br/>&gt; 1h50m review mail <br/>&gt; 45m PathTools version portability <br/>&gt; 42m [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz <br/>&gt; 36m [perl #132788] Blead Breaks CPAN: <br/>&gt; LEMBARK/Object-Trampoline-1.42.tar.gz <br/>&gt; 33m [perl #132760] Blead Breaks CPAN: <br/>&gt; YANICK/List-Lazy-0.3.0.tar.gz <br/>&gt; 29m [perl #132873] Blead Breaks CPAN: JOHNH/Fsdb-2.64.tar.gz <br/>&gt; 20m [perl #7515] perlio bug ? <br/>&gt; 8h23m TOTAL <br/>&gt; <br/>&gt; At the end of the week there was 51h32m of authorised working time <br/>&gt; remaining in this grant. <br/>&gt; <br/>&gt; -zefram <br/> <br/>thanks for your work! <br/> <br/>-- <br/>----------------------------------------------------------------- <br/>Shlomi Fish http://www.shlomifish.org/ <br/>Perl Humour - http://perl-begin.org/humour/ <br/> <br/>People who think they know everything greatly annoy those of us who do. <br/> &mdash; Source unknown, via Linux&rsquo;s fortune-mod <br/> <br/>Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply . <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249586.html Thu, 22 Feb 2018 09:23:58 +0000 Re: [perl #132892] Possibly memory leak when matching strings usingpre-compiled regexes stored in hash key (perl >= v5.26) by Shlomi Fish On Wed, 21 Feb 2018 07:49:20 -0800 <br/>(via RT) &lt;perlbug-followup@perl.org&gt; wrote: <br/> <br/>&gt; # New Ticket Created by <br/>&gt; # Please include the string: [perl #132892] <br/>&gt; # in the subject line of all future correspondence about this issue. <br/>&gt; # &lt;URL: https://rt.perl.org/Ticket/Display.html?id=132892 &gt; <br/>&gt; <br/>&gt; <br/> <br/>Hi all! <br/> <br/>I reworked the example code to remove some potential problems, and verified <br/>that htop sees its RAM consumption increasing: <br/> <br/>#!/usr/bin/perl <br/> <br/>use strict; <br/>use warnings; <br/> <br/># my $getmem = &quot;ps -o vsz= -o rss= -p $$&quot;, <br/> <br/>print &quot;== Test result on $^O perl-$^V\n&quot;; <br/> <br/>my %h = ( <br/> qr{abcd} =&gt; [ &#39;ABCD&#39;, 2], <br/> qr{efgh} =&gt; [ &#39;EFGH&#39;, 1], <br/> qr{ijkl} =&gt; [ &#39;IJKL&#39;, 1], <br/> qr{mnop} =&gt; [ &#39;MNOP&#39;, 1], <br/> qr{qrst} =&gt; [ &#39;QRST&#39;, 1], <br/> qr{uvwx} =&gt; [ &#39;UVWX&#39;, 1], <br/>); <br/> <br/>my @list = qw/ abcd abcd efgh ijkl mnop qrst uvwx /; <br/> <br/>while (1) { <br/> # system($getmem); <br/> for my $r (keys %h) { <br/> my $c = 0; <br/> my ($name, $expected) = @{$h{$r}}; <br/> for my $e ( @list ) { <br/> $c++ if $e =~ $r; <br/> } <br/> <br/> print &quot;&gt;&gt;&gt; Count mismatch for $name\n&quot; if ( $c != $expected ); <br/> } <br/>} <br/> <br/> <br/> <br/>&gt; Hello guys, <br/>&gt; <br/>&gt; I have a long running perl script which allows the user configure the <br/>&gt; program behavior with a hash that got pre-compiled regexps <br/>&gt; as keys and the corresponding callback code as the value like below. <br/>&gt; Recently I have upgraded to perl v5.26 and the memory <br/>&gt; usage grows since then, so I have fall back to perl v5.24.3 as a temporary <br/>&gt; solution. What I observed before fallback is that the <br/>&gt; memory grows when I try to iterates the hash keys and matches them against <br/>&gt; some text. <br/>&gt; <br/>&gt; %action = ( <br/>&gt; <br/>&gt; qr/^regex here/ =&gt; sub { print &quot;match&quot; }, <br/>&gt; <br/>&gt; ); <br/>&gt; <br/>&gt; <br/>&gt; I have written a small test for this problem, you can find it in the <br/>&gt; attached perlbug.tar.xz. 20180221-mem-leak-poc.pl is the prof of <br/>&gt; concept code. It will output the platform and perl version as the first <br/>&gt; line, and make use of the ps command to retrieve the vsz and <br/>&gt; rss of the perl interpreter before each iteration. The test result of <br/>&gt; different platform are stored in the rslt/ sub-directory for your reference. <br/>&gt; According to the results, with perl &lt;v5.26, the size in memory remain <br/>&gt; unchanged; While the memory usage keeps increasing when the <br/>&gt; script is run with perl &gt;=v5.26. I have limited the number of iteration, <br/>&gt; the memory usage grows further if you increases the number of iteration. <br/>&gt; <br/>&gt; |-- 20180221-mem-leak-poc.pl <br/>&gt; `-- rslt <br/>&gt; |-- centos6-p5.10.1.log <br/>&gt; |-- centos6-p5.24.3.log <br/>&gt; |-- centos6-p5.26.1.log <br/>&gt; |-- centos6-p5.27.8.log <br/>&gt; |-- dfbsd-p5.24.3.log <br/>&gt; |-- dfbsd-p5.26.1.log <br/>&gt; |-- freebsd-p5.24.3.log <br/>&gt; `-- freebsd-p5.26.1.log <br/>&gt; <br/>&gt; According to my empirical result, this problem occurs when using perl newer <br/>&gt; than v5.26, the first line of perl -v of the affected perl <br/>&gt; interpreters below. <br/>&gt; <br/>&gt; &gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for amd64-freebsd <br/>&gt; &gt; This is perl 5, version 27, subversion 8 (v5.27.8) built for x86_64-linux <br/>&gt; &gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux <br/>&gt; <br/>&gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for <br/>&gt; &gt; x86_64-dragonfly <br/>&gt; <br/>&gt; <br/>&gt; I have traced the problem a little bit and I *guess* the problem is in the <br/>&gt; function S_concat_pat of regcomp.c and the new SVs <br/>&gt; copied out are immortal, so every time my program iterate through the keys <br/>&gt; of hash to match against things, it creates more <br/>&gt; copies of the regexes. I can try to dig deeper when I am free to build the <br/>&gt; debug versions of perl, but that would be great if this <br/>&gt; case can be taken care by the professionals here. Thanks a lot. <br/>&gt; &#x200B; <br/>&gt; <br/>&gt; &#x200B; <br/>&gt; Best regards, <br/>&gt; Baggio <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249585.html Thu, 22 Feb 2018 09:04:06 +0000 Re: Food for thought? Fw: [opensuse-factory] y2k-bug reloaded by Dave Mitchell On Wed, Feb 21, 2018 at 09:34:39PM +0100, H.Merijn Brand wrote:<br/>&gt; From: &quot;Bernhard M. Wiedemann&quot; &lt;bernhardout@lsmod.de&gt;<br/>&gt; Related: software that assumes that this will print 0<br/>&gt;<br/>&gt; perl -e &#39;use Time::Local; print Time::Local::timelocal(localtime(0))&#39;<br/>&gt;<br/>&gt; will break in 2020, because localtime returns a year of 70 and timelocal<br/>&gt; will then interpret that as 2070.<br/><br/>Time::Local::timelocal() is behaving as documented - special-casing<br/>2-digit years to make it more human-readable friendly. One effect of that<br/>is that in the year 2020 onwards, trying to convert back the output<br/>of localtime(0), which returns a year value of 70 for the epoch year of<br/>1970, will fail.<br/><br/>Arguably Time::Local could be extended to have a couple of extra methods,<br/>such as timelocal_strict() say, which interprets the year value strictly<br/>as something that would have been returned by localtime() rather than<br/>a human-friendly fudging.<br/><br/>Then any modules which use Time::Local and expect a safe round-trip for<br/>any year, should switch to using the new functions.<br/><br/>-- <br/>The crew of the Enterprise encounter an alien life form which is<br/>surprisingly neither humanoid nor made from pure energy.<br/> -- Things That Never Happen in &quot;Star Trek&quot; #22<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249584.html Thu, 22 Feb 2018 08:48:49 +0000 [perl #132860] RFC on windows build status by bulk88 via RT On Wed, 21 Feb 2018 19:04:12 -0800, demerphq wrote:<br/>&gt; On 22 Feb 2018 03:04, &quot;bulk88 via RT&quot; &lt;perlbug-followup@perl.org&gt; wrote:<br/>&gt; <br/>&gt; On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote:<br/>&gt; &gt; Since this is Win64 key_len is 64 bit int, that is XORed with state[2]<br/>&gt; &gt; which is a U32 and the result is assigned to a U32, truncating high<br/>&gt; &gt; bytes. Hence the warning. It seems zaphod32_hash_with_state code is<br/>&gt; &gt; unique to you (demerphq) and not FOSS code borrowed from somewhere<br/>&gt; &gt; else, so there is no upstream to go consult about the truncation.<br/>&gt; <br/>&gt; <br/>&gt; It is Foss, but it is also my work.&eth;&#159;&#152;&#128;<br/>&gt; <br/>&gt; The truncation shouldn&#39;t matter, but it shouldn&#39;t throw an error either.<br/><br/>Cast to U32 before assigning to U32 will quiet MSVC.<br/><br/><br/>&gt; However with the way that we use sbox32 in perl we will do a similar fall<br/>&gt; through logic *before* we enter sbox32, but on 64 bit builds we will use<br/>&gt; stadtx64 instead of zaphod32.<br/><br/>If you dont do the NOT_REACHED (I prefer that) more macros are needed so the inside of sbox32 matches the primary long key algo. Or have the primary long key algo only from the inside and make it so there is no way to use sbox32 for long keys.<br/><br/>&gt; Yep. You could change when this happens with the right -D to configure.<br/><br/>Probably nobody ever will, but still, if the fallback is from inside sbox, then the fallback should only be from sbox, not from the outer _PERL_HASH_WITH_STATE. Basically sbox CANT be compiled to be used in isolation.<br/><br/>&gt; Yep. Will do.<br/><br/>Yes please.<br/><br/>&gt; I assumed a good compiler would elide this unused code...<br/><br/>A good linker will toss the code, a compiler CANT toss the code and had to spend CPU to generate ASM. Really bad linkers/bad OSes wont toss the code due to GOT/&quot;debugging&quot; reasons (call a static func explicitly with gdb).<br/><br/>&gt; <br/>&gt; I&#39;ll dig further when I get a chance.<br/><br/>A U32 cast is the quick and dirty way to fix it aslong as truncation is okay of that XOR, truncation is happening anyway on all 64b OSes whether a CC warns or not.<br/><br/>-- <br/>bulk88 ~ bulk88 at hotmail.com<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132860<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249583.html Thu, 22 Feb 2018 05:35:32 +0000 Re: Release 5.27.9 is available now! by Karl Williamson On 02/20/2018 01:49 PM, Renee B wrote: <br/>&gt; Poirot was an extraordinary looking little man. He was hardly more <br/>&gt; than five feet, four inches, but carried himself with great dignity. <br/>&gt; His head was exactly the shape of an egg, and he always perched it <br/>&gt; a little on one side. His moustache was very stiff and military. <br/>&gt; The neatness of his attire was almost incredible. I believe a <br/>&gt; speck of dust would have caused him more pain than a bullet wound. <br/>&gt; Yet this quaint dandified little man who, I was sorry to see, now <br/>&gt; limped badly, had been in his time one of the most celebrated members <br/>&gt; of the Belgian police. As a detective, his flair had been extraordinary, <br/>&gt; and he had achieved triumphs by unravelling some of the most baffling <br/>&gt; cases of the day. <br/>&gt; He pointed out to me the little house inhabited by him and his fellow <br/>&gt; Belgians, and I promised to go and see him at an early date. Then he <br/>&gt; raised his hat with a flourish to Cynthia, and we drove away. <br/>&gt; &quot;He&#39;s a dear little man,&quot; said Cynthia. &quot;I&#39;d no idea you knew him.&quot; <br/>&gt; &quot;You&#39;ve been entertaining a celebrity unawares,&quot; I replied. <br/>&gt; And, for the rest of the way home, I recited to them the various <br/>&gt; exploits and triumphs of Hercule Poirot. <br/>&gt; <br/>&gt; -- Agatha Christie, The Mysterious Affair at Styles, p. 14 <br/>&gt; <br/>&gt; We are &#39;pleased&#39; to announce version 5.27.9, <br/>&gt; the tenth development release of version 27 of Perl 5. <br/>&gt; <br/>&gt; You will soon be able to download Perl 5.27.9 from your <br/>&gt; favorite CPAN mirror or find it at: <br/>&gt; <br/>&gt; https://metacpan.org/release/RENEEB/perl-5.27.9/ <br/>&gt; <br/>&gt; SHA1 digests for this release are: <br/>&gt; <br/>&gt; d2508d0f3f761cf06260dda54c3ae22314ad9d7c perl-5.27.9.tar.gz <br/>&gt; 6f31cd1f524fa37e29b0d8512bacf8e351fd4683 perl-5.27.9.tar.xz <br/>&gt; <br/>&gt; You can find a full list of changes in the file &quot;perldelta.pod&quot; located in <br/>&gt; the &quot;pod&quot; directory inside the release and on the web at <br/>&gt; <br/>&gt; https://metacpan.org/pod/release/RENEEB/perl-5.27.9/pod/perldelta.pod <br/> <br/>blead has not been updated to include this. <br/> <br/>&gt; <br/>&gt; Perl 5.27.9 represents approximately 5 weeks of development since Perl <br/>&gt; 5.27.8 and contains approximately 29,000 lines of changes across 360 files <br/>&gt; from 26 authors. <br/>&gt; <br/>&gt; Excluding auto-generated files, documentation and release tools, there were <br/>&gt; approximately 13,000 lines of changes to 250 .pm, .t, .c and .h files. <br/>&gt; <br/>&gt; Perl continues to flourish into its third decade thanks to a vibrant <br/>&gt; community of users and developers. The following people are known to have <br/>&gt; contributed the improvements that became Perl 5.27.9: <br/>&gt; <br/>&gt; Aaron Crane, Abigail, Chris &#39;BinGOs&#39; Williams, Craig A. Berry, Dagfinn <br/>&gt; Ilmari Manns&aring;ker, David Mitchell, Father Chrysostomos, George Hartzell, <br/>&gt; H.Merijn Brand, Hugo van der Sanden, James E Keenan, Jerry D. Hedden, Karl <br/>&gt; Williamson, Matthew Horsfall, Pali, Reini Urban, Sawyer X, Slaven Rezic, <br/>&gt; Steve Hay, Todd Rinaldo, Tomasz Konojacki, Tom Wyant, Tony Cook, Yves Orton, <br/>&gt; Zefram. <br/>&gt; <br/>&gt; The list above is almost certainly incomplete as it is automatically <br/>&gt; generated from version control history. In particular, it does not include <br/>&gt; the names of the (very much appreciated) contributors who reported issues to <br/>&gt; the Perl bug tracker. <br/>&gt; <br/>&gt; Many of the changes included in this version originated in the CPAN modules <br/>&gt; included in Perl&#39;s core. We&#39;re grateful to the entire CPAN community for <br/>&gt; helping Perl to flourish. <br/>&gt; <br/>&gt; For a more complete list of all of Perl&#39;s historical contributors, please <br/>&gt; see the F&lt;AUTHORS&gt; file in the Perl source distribution. <br/>&gt; <br/>&gt; We expect to release version 27.9 on March 20th, 2018. <br/>&gt; The next major stable release of Perl 5, version 28.0, should <br/>&gt; appear in May 2018. <br/>&gt; <br/>&gt; Kind regards, <br/>&gt; Ren&eacute;e <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249582.html Thu, 22 Feb 2018 05:23:29 +0000 [perl #132894] Blead Breaks CPAN:MAROS/DateTime-Format-CLDR-1.19.tar.gz by =?UTF-8?B?TWFyb8WhIEtvbGzDoXI=?= via RT Might be related to https://github.com/houseabsolute/DateTime.pm/issues/29<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132894<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249581.html Thu, 22 Feb 2018 04:39:33 +0000 [perl #132849] Perl build process leaves random files in system by Shoichi Kaji via RT It is true that the perl build does not leave core files anymore,<br/>but it still emits &quot;Segmentation fault (core dumped)&quot; message on my environment.<br/>https://gist.github.com/skaji/4fb507113bb7a05a9514e323a001b9a3<br/><br/>It would be nice if it does not emit such messages either. <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249580.html Thu, 22 Feb 2018 04:39:28 +0000 [perl #132892] Possibly memory leak when matching strings usingpre-compiled regexes stored in hash key (perl >= v5.26) by perlbug-followup # New Ticket Created by <br/># Please include the string: [perl #132892]<br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=132892 &gt;<br/><br/><br/>Hello guys,<br/><br/>I have a long running perl script which allows the user configure the<br/>program behavior with a hash that got pre-compiled regexps<br/>as keys and the corresponding callback code as the value like below.<br/>Recently I have upgraded to perl v5.26 and the memory<br/>usage grows since then, so I have fall back to perl v5.24.3 as a temporary<br/>solution. What I observed before fallback is that the<br/>memory grows when I try to iterates the hash keys and matches them against<br/>some text.<br/><br/>%action = (<br/><br/> qr/^regex here/ =&gt; sub { print &quot;match&quot; },<br/><br/>);<br/><br/><br/>I have written a small test for this problem, you can find it in the<br/>attached perlbug.tar.xz. 20180221-mem-leak-poc.pl is the prof of<br/>concept code. It will output the platform and perl version as the first<br/>line, and make use of the ps command to retrieve the vsz and<br/>rss of the perl interpreter before each iteration. The test result of<br/>different platform are stored in the rslt/ sub-directory for your reference.<br/>According to the results, with perl &lt;v5.26, the size in memory remain<br/>unchanged; While the memory usage keeps increasing when the<br/>script is run with perl &gt;=v5.26. I have limited the number of iteration,<br/>the memory usage grows further if you increases the number of iteration.<br/><br/>|-- 20180221-mem-leak-poc.pl<br/>`-- rslt<br/> |-- centos6-p5.10.1.log<br/> |-- centos6-p5.24.3.log<br/> |-- centos6-p5.26.1.log<br/> |-- centos6-p5.27.8.log<br/> |-- dfbsd-p5.24.3.log<br/> |-- dfbsd-p5.26.1.log<br/> |-- freebsd-p5.24.3.log<br/> `-- freebsd-p5.26.1.log<br/><br/>According to my empirical result, this problem occurs when using perl newer<br/>than v5.26, the first line of perl -v of the affected perl<br/>interpreters below.<br/><br/>&gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for amd64-freebsd<br/>&gt; This is perl 5, version 27, subversion 8 (v5.27.8) built for x86_64-linux<br/>&gt; This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux<br/><br/>This is perl 5, version 26, subversion 1 (v5.26.1) built for<br/>&gt; x86_64-dragonfly<br/><br/><br/>I have traced the problem a little bit and I *guess* the problem is in the<br/>function S_concat_pat of regcomp.c and the new SVs<br/>copied out are immortal, so every time my program iterate through the keys<br/>of hash to match against things, it creates more<br/>copies of the regexes. I can try to dig deeper when I am free to build the<br/>debug versions of perl, but that would be great if this<br/>case can be taken care by the professionals here. Thanks a lot.<br/>&acirc;&#128;&#139;<br/><br/>&acirc;&#128;&#139;<br/>Best regards,<br/>Baggio<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249579.html Thu, 22 Feb 2018 04:39:27 +0000 [perl #132893] Storable build hangs when building 5.27.9 on WindowsXP by Tony Cook via RT On Wed, 21 Feb 2018 10:46:33 -0800, chorny wrote:<br/>&gt; ..\perl.exe -I..\lib -I. ..\dist\Storable\stacksize --core<br/>&gt; probe for max. stack sizes...<br/>&gt; 65000 failed, try less 32550 ...<br/>&gt; 32550 failed, try less 16325 ...<br/>&gt; 16325 failed, try less 8213 ...<br/>&gt; 8213 failed, try less 4157 ...<br/>&gt; 4157 passed, try more 6185 ...<br/>&gt; 6185 passed, try more 7199 ...<br/>&gt; 7199 failed, try less 6692 ...<br/>&gt; 6692 failed, try less 6439 ...<br/>&gt; 6439 failed, try less 6312 ...<br/>&gt; 6312 failed, try less 6249 ...<br/>&gt; 6249 failed, try less 6217 ...<br/>&gt; 6217 failed, try less 6201 ...<br/>&gt; 6201 failed, try less 6193 ...<br/>&gt; 6193 passed, try more 6197 ...<br/>&gt; 6197 passed, try more 6199 ...<br/>&gt; 6199 passed, try more 6200 ...<br/>&gt; 6200 passed, try more 6200 ...<br/>&gt; MAX_DEPTH = 6200<br/>&gt; 3100 passed, try more 4650 ...<br/>&gt; 4650 passed, try more 5425 ...<br/>&gt; 5425 passed, try more 5812 ...<br/>&gt; Out of memory!<br/>&gt; (hangs)<br/>&gt; <br/><br/>I&#39;ve reproduced this. It requires USE_64_BIT_INT, I haven&#39;t managed to track down the cause yet.<br/><br/>&gt; Also `stacksize` is executed on every stage - build/tests/install, so<br/>&gt; I had to kill it 3 times. After killing hanging process, stacksize<br/>&gt; continues search.<br/>&gt; This is same problem as with Storable on CPAN. In CPAN version I<br/>&gt; solved it with Win32::Job, but it is not a core module. See<br/>&gt; https://github.com/rurban/Storable/pull/2<br/>&gt; It should be possible to use Win32::Process, but it is not a core<br/>&gt; module either.<br/><br/>I&#39;ll see if I can prevent running the probe several times, probably by having the rule in win32/(GNU)?[mM]akefile(.mk)? run a sub-make in the Storable directory instead of running it directly.<br/><br/>&gt; <br/>&gt; cpantesters results show that with RURBAN/Storable-3.05_16.tar.gz<br/>&gt; these values can be partially predicted. Note that values for 3.05_16<br/>&gt; on CPAN and 3.06 in core are different. And `stacksize` in 3.05_16<br/>&gt; currently does not hang even when not using Win32::Job.<br/>&gt; <br/>&gt; Windows 10 64-bit, perl 5.26.0 64-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows 10 64-bit, perl 5.22.1 32-bit+64-bit int:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows 10 64-bit, perl 5.22.1 64-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows 10 64-bit, perl 5.24.0 32-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit inside VM, perl 5.20.1 32-bit+64-bit int:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit inside VM, perl 5.18.2 32-bit+64-bit int:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit inside VM, perl 5.18.2 32-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=512<br/>&gt; Windows XP 32-bit inside VM, perl 5.26.0 32-bit+64-bit int:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=512<br/>&gt; Windows XP 32-bit inside VM, perl 5.12.2 32-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit, perl 5.27.9 32-bit+64-bit int:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit, perl 5.14.0 32-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/>&gt; Windows XP 32-bit inside VM, perl 5.16.0, 5.16.3 32-bit:<br/>&gt; PST_STACK_MAX_DEPTH=513<br/>&gt; PST_STACK_MAX_DEPTH_HASH=257<br/><br/>Those values are just stacksize falling back to a default.<br/><br/>A predefined table is going to vary based on bitness of build, debug/non-debug, whether USE_64_BIT_INT is set, version of perl, compiler, compiler version and changes to Storable itself.<br/><br/>The builder of perl may adjust the stack size too.<br/><br/>That&#39;s just too many dimensions.<br/><br/>I may just do what Reini did and fallback to a default on difficult platforms like XP.<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132893<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249578.html Thu, 22 Feb 2018 04:25:52 +0000 [perl #132875] Blead Breaks CPAN: ZDM/Pcore-v0.56.5.tar.gz by Father Chrysostomos via RT On Wed, 21 Feb 2018 01:31:28 -0800, davem wrote:<br/>&gt; On Tue, Feb 20, 2018 at 05:31:49PM +0100, demerphq wrote:<br/>&gt; &gt; Is it possible we could exempt variable not declared errors from this<br/>&gt; &gt; change?<br/>&gt; &gt;<br/>&gt; &gt; The biggest value I see of continuing parsing and showing more errors<br/>&gt; &gt; is it<br/>&gt; &gt; allows one to avoid playing whack-a-mole when dealing with such<br/>&gt; &gt; errors. You<br/>&gt; &gt; can find and fix multiple variable uses and etc in one go. If this<br/>&gt; &gt; was<br/>&gt; &gt; still possible then I don&#39;t think stopping on the first error of<br/>&gt; &gt; other<br/>&gt; &gt; types would even be noticed....<br/>&gt; <br/>&gt; Well, the rationale for for bailing out on the first error is that at<br/>&gt; that<br/>&gt; point the lexer and parser are in an unknown and possibly inconsistent<br/>&gt; state. Continuing to parse after that point to detect any further<br/>&gt; errors<br/>&gt; is likely to trigger bugs. In fact fuzzing over recent years has<br/>&gt; shown<br/>&gt; that there is a large supply of such bugs, and I doubt that we would<br/>&gt; ever<br/>&gt; detect and fix them them all (perl&#39;s lexer being over 12K LoC).<br/>&gt; <br/>&gt; So continuing is bad enough; continuing and possibly emitting further<br/>&gt; warnings is even worse, as that could trigger a call to a<br/>&gt; $SIG{__WARN__}<br/>&gt; and thus you&#39;re now actually executing code while the interpreter is<br/>&gt; in an<br/>&gt; inconsistent state.<br/><br/>$SIG{__WARN__} seems awfully similar to BEGIN blocks. It probably shouldn&acirc;&#128;&#153;t be allowed when PL_error_count is positive. (Instead, a error gets thrown.) But that might be too intrusive a change.<br/><br/>Though what Yves suggests is a plausible alternative.<br/><br/>-- <br/><br/>Father Chrysostomos<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132875<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249577.html Thu, 22 Feb 2018 03:51:12 +0000 Re: [perl #132860] RFC on windows build status by demerphq On 22 Feb 2018 03:04, &quot;bulk88 via RT&quot; &lt;perlbug-followup@perl.org&gt; wrote: <br/> <br/>On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote: <br/>&gt; Since this is Win64 key_len is 64 bit int, that is XORed with state[2] <br/>&gt; which is a U32 and the result is assigned to a U32, truncating high <br/>&gt; bytes. Hence the warning. It seems zaphod32_hash_with_state code is <br/>&gt; unique to you (demerphq) and not FOSS code borrowed from somewhere <br/>&gt; else, so there is no upstream to go consult about the truncation. <br/> <br/> <br/>It is Foss, but it is also my work.&eth;&#159;&#152;&#128; <br/> <br/>The truncation shouldn&#39;t matter, but it shouldn&#39;t throw an error either. <br/> <br/> <br/>I see a bigger problem with the new hash code. I put a __builtin_trap() <br/>right before &quot;U32 v2 = state[2] ^ (0xC41A7AB1 * (key_len + 1));&quot; and did a <br/>&quot;make test&quot;. It NEVER executed. I checked the machine code, and yes <br/>zaphod32_hash_with_state/__builtin_trap is linked in and I can see how <br/>theoretically executed, but it is unreachable in real life. <br/> <br/> <br/>This is a build option issue. Sbox hashing is very fast, but has a finite <br/>capacity, and falls through to zaphod32 when that capacity is exceeded. <br/> <br/>However with the way that we use sbox32 in perl we will do a similar fall <br/>through logic *before* we enter sbox32, but on 64 bit builds we will use <br/>stadtx64 instead of zaphod32. <br/> <br/> <br/> <br/>zaphod32_hash_with_state is ONLY referenced by sbox32_hash_with_state. <br/> <br/>------------------------------- <br/>static __inline U32 <br/>sbox32_hash_with_state(const U8 * state_ch, <br/> const U8 * key, const STRLEN key_len) <br/>{ <br/> U32 *state = (U32 *) state_ch; <br/> U32 hash = *state; <br/> switch (key_len) { <br/> default: <br/> return zaphod32_hash_with_state(state_ch, key, key_len); <br/> <br/> case 24: <br/>-------------------------------- <br/> <br/>That is the only reference. <br/> <br/>But if I look at the callers of sbox32_hash_with_state, there are 18 <br/>callers, but all of then do the len &lt;= 24 check. Example of usage. <br/> <br/> <br/>Yep. You could change when this happens with the right -D to configure. <br/> <br/> <br/>------------------------------- <br/>static __inline U32 <br/>S_perl_hash_with_seed(const U8 * const seed, const U8 * const str, <br/> const STRLEN len) <br/>{ <br/> U8 state[(32 + ((1 + (256 * 24)) * sizeof(U32)))]; <br/> do { <br/> stadtx_seed_state(seed, state); <br/> sbox32_seed_state96(seed + 16, state + 32); <br/> } while (0); <br/> return ((((len &lt;= <br/> 24) ? (char) 1 : (char) 0)) ? sbox32_hash_with_state((state <br/> + 32), <br/> (U8 <br/> *) <br/> (str), <br/> (len)) <br/> : (U32) stadtx_hash_with_state(((state)), (U8 *) ((str)), <br/> ((len)))); <br/>} <br/>------------------------------- <br/>So sbox32_hash_with_state can&#39;t be reached with a key longer than 24, yet <br/>sbox32_hash_with_state has a default: for a key longer than 24. The <br/>default: in sbox32_hash_with_state needs to be &quot;NOT_REACHED;&quot; and maybe an <br/>assert. That would remove zaphod32_hash_with_state() from the binary since <br/>on 64 bit OSes stadtx is used, not zaphod for long keys. <br/> <br/> <br/>Yep. Will do. <br/> <br/> <br/>I also think there is too much code not ifdefed out in hv_func.h <br/> <br/>sbox32_hash128 has no uses, it should be #if 0&#39;ed so it doesn&#39;t reach the <br/>C-&gt;Asm stage. sbox32_seed_state128 whose only ref is sbox32_hash128 also <br/>can #if 0, since S_perl_hash_with_seed uses sbox32_seed_state96. <br/>sbox32_hash96 can also be if #0. <br/> <br/>S_perl_hash_siphash_2_4 <br/>S_perl_hash_siphash_2_4_with_state <br/>S_perl_hash_siphash_1_3 <br/>S_perl_hash_siphash_1_3_with_state <br/>S_perl_siphash_seed_state <br/> <br/>are also in the .i file event though perl is uses the <br/>PERL_HASH_USE_SBOX32_ALSO sbox/stadtx or sbox/zaphos pair. Those need <br/>ifdefs too. <br/> <br/> <br/>I assumed a good compiler would elide this unused code... <br/> <br/>I&#39;ll dig further when I get a chance. <br/> <br/>Thanks, <br/>Yves <br/> <br/> <br/>-- <br/>bulk88 ~ bulk88 at hotmail.com <br/> <br/>--- <br/>via perlbug: queue: perl5 status: open <br/>https://rt.perl.org/Ticket/Display.html?id=132860 <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249576.html Thu, 22 Feb 2018 03:04:07 +0000 [perl #132894] Blead Breaks CPAN:MAROS/DateTime-Format-CLDR-1.19.tar.gz by slaven@rezic.de via RT Dana Wed, 21 Feb 2018 13:44:48 -0800, zefram@fysh.org re&Auml;&#141;e:<br/>&gt; slaven@rezic.de wrote:<br/>&gt; &gt;The t/011_nanosecond.t of DateTime-Format-CLDR-1.19 test started to<br/>&gt; &gt;fail at some point between 5.27.8 and 5.27.9.<br/>&gt; <br/>&gt; Fails for me in that manner on both 5.27.8 and 5.27.9. On my test perls,<br/>&gt; it fails in this manner on all perls from 5.21.4 onwards. So this<br/>&gt; doesn&#39;t look like a current BBC.<br/>&gt; <br/>&gt; On older perls I see it failing on some versions and passing on other<br/>&gt; versions in a really unusual pattern, which makes me suspect that it<br/>&gt; actually depends on which version of some other module is installed,<br/>&gt; perhaps DateTime::Locale.<br/><br/>Does not seem so --- I run the test script with Module::PrintUsed on the failing linux and passing freebsd system, and the only difference is:<br/><br/> - Test::NoWarnings 1.04<br/> - Test::NoWarnings::Warning 1.04<br/> - Test2::API 1.302122<br/>+ - Test2::API::Breakage 1.302122<br/> - Test2::API::Context 1.302122<br/> - Test2::API::Instance 1.302122<br/> - Test2::API::Stack 1.302122<br/><br/>... which is expected, as Test2::API::Breakage is loaded only if a failure occurs.<br/><br/>&gt; (DT:F:CLDR is failing where there&#39;s a new<br/>&gt; DT:L and succeeding where there&#39;s an old one. I have an old DT:L<br/>&gt; on some versions because the new DT:L&#39;s deps have porting problems.)<br/>&gt; But there&#39;s also some dependence on the floating point format: prior to<br/>&gt; 5.21.4 I only see the failures on nvtype=double builds, while it succeeds<br/>&gt; on nvtype=long double builds regardless of the versions of other modules.<br/>&gt; (The failures from 5.21.4 happen regardless of nvtype.)<br/>&gt; <br/>&gt; I&#39;ll look some more.<br/>&gt; <br/>&gt; -zefram<br/><br/><br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132894<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249575.html Wed, 21 Feb 2018 22:08:24 +0000 Re: [perl #132894] Blead Breaks CPAN:MAROS/DateTime-Format-CLDR-1.19.tar.gz by Zefram slaven@rezic.de wrote:<br/>&gt;The t/011_nanosecond.t of DateTime-Format-CLDR-1.19 test started to<br/>&gt;fail at some point between 5.27.8 and 5.27.9.<br/><br/>Fails for me in that manner on both 5.27.8 and 5.27.9. On my test perls,<br/>it fails in this manner on all perls from 5.21.4 onwards. So this<br/>doesn&#39;t look like a current BBC.<br/><br/>On older perls I see it failing on some versions and passing on other<br/>versions in a really unusual pattern, which makes me suspect that it<br/>actually depends on which version of some other module is installed,<br/>perhaps DateTime::Locale. (DT:F:CLDR is failing where there&#39;s a new<br/>DT:L and succeeding where there&#39;s an old one. I have an old DT:L<br/>on some versions because the new DT:L&#39;s deps have porting problems.)<br/>But there&#39;s also some dependence on the floating point format: prior to<br/>5.21.4 I only see the failures on nvtype=double builds, while it succeeds<br/>on nvtype=long double builds regardless of the versions of other modules.<br/>(The failures from 5.21.4 happen regardless of nvtype.)<br/><br/>I&#39;ll look some more.<br/><br/>-zefram<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2018/02/msg249574.html Wed, 21 Feb 2018 21:44:43 +0000