perl.perl5.porters https://www.nntp.perl.org/group/perl.perl5.porters/ ... Copyright 1998-2019 perl.org Mon, 18 Feb 2019 21:20:59 +0000 ask@perl.org Perl5 Bug Summary by Perl5 Bug Summary Perl5 Bug Summary<br/><br/>http://rt.perl.org/NoAuth/perl5/Overview.html<br/>Generated at Mon Feb 18 16:17:01 2019 GMT<br/>-------------------------------------------------------------------------------<br/><br/> * Numbers<br/> * New Issues<br/> * Overview of Open Issues<br/> * Ticket Status By Version<br/> * Requestors with most open tickets<br/><br/>-------------------------------------------------------------------------------<br/><br/>Numbers<br/><br/>Ticket Counts: 149 new + 1677 open = 1826<br/>Created this week: 4<br/>Closed this week: 7<br/>Changed this week: 18 - created - closed = 7<br/><br/>-------------------------------------------------------------------------------<br/><br/>New Issues<br/><br/>New issues that have not been responded to yet<br/><br/>1 - 2 weeks old<br/>2 - 3 weeks old<br/>133816 BBC: 4288c5b broke test in CPAN module XML::Easy<br/>3 - 4 weeks old<br/>4 - 5 weeks old<br/>5 - 6 weeks old<br/>6 - 7 weeks old<br/>133754 Test failures on Windows with 8.3 filenames disabled<br/>7 - 8 weeks old<br/>8 - 9 weeks old<br/>9 - 10 weeks old<br/>133727 Configuration option &#39;-DPERL_POISON&#39; not documented<br/>133720 bug in do-block scoping<br/>10 - 11 weeks old<br/>133709 in-place edit does not replace files during non-global cleanup<br/>11 - 12 weeks old<br/>133707 Document formal grammar for regex sets<br/>12 - 13 weeks old<br/>13 - 14 weeks old<br/>14 - 15 weeks old<br/>15 - 16 weeks old<br/>16 - 17 weeks old<br/>17 - 18 weeks old<br/>18 - 19 weeks old<br/>19 - 20 weeks old<br/>133556 [META] Build-time warnings<br/>20 - 21 weeks old<br/><br/>-------------------------------------------------------------------------------<br/><br/>Overview of Open Issues<br/><br/>Operating System Severity Type Perl Version<br/><br/>aix 5 High 98 3Dlibrary 1 5.000 1<br/><br/>All 119 low 1196 BBC 12 5.004 1<br/><br/>cygwin 22 medium 296 compiler 1 5.004_00 1<br/><br/>darwin 77 none 4 configure 20 5.004_01 1<br/><br/>dec_osf 1 Normal 1 core 797 5.004_02 1<br/><br/>dos 1 unknown 1 CoreDump 35 5.004_03 1<br/><br/>freebsd 22 Wishlist 107 dailybuild 1 5.004_04 1<br/><br/>generic 5 debugger 11 5.004_05 1<br/><br/>gnu 1 docs 45 5.005 1<br/><br/>HPUX 6 HasTest 17 5.005_01 1<br/><br/>irix 2 install 34 5.005_02 1<br/><br/>Linux 529 ithreads 35 5.005_03 4<br/><br/>mswin32 105 leak/refcount/malloc 23 5.005_04 2<br/><br/>netbsd 2 lexical/scope/closure 17 5.6.0 21<br/><br/>openbsd 11 library 216 5.6.1 17<br/><br/>os2 5 locale 1 5.6.2 3<br/><br/>other 2 meta 22 5.7.0 2<br/><br/>Solaris 19 NeedsTest 9 5.7.1 2<br/><br/>sunos 1 notabug 7 5.7.2 4<br/><br/>svr4 1 numerical 16 5.8.0 37<br/><br/>unknown 1 OO/ISA/MRO/overload 5 5.8.1 10<br/><br/>vms 3 OS-interaction 54 5.8.2 11<br/><br/>Win32 49 parsing 14 5.8.3 12<br/><br/> Patch 45 5.8.4 18<br/><br/> performance 6 5.8.5 8<br/><br/> PerlIO 49 5.8.6 14<br/><br/> portability 44 5.8.7 16<br/><br/> regex 38 5.8.8 58<br/><br/> security/tainting 4 5.8.9 6<br/><br/> sendToCPAN 2 5.9.0 6<br/><br/> tie 4 5.9.1 4<br/><br/> Todo 2 5.9.2 4<br/><br/> Unicode 24 5.9.3 4<br/><br/> unknown 557 5.9.4 4<br/><br/> utilities 36 5.9.5 8<br/><br/> wontfix 1 5.10.0 72<br/><br/> XS/embedding 11 5.10.1 47<br/><br/> [overload] 5.11.0 11<br/><br/> 5.11.1 3<br/><br/> 5.11.2 1<br/><br/> 5.11.3 3<br/><br/> 5.11.4 2<br/><br/> 5.11.5 2<br/><br/> 5.12.0 6<br/><br/> 5.12.1 9<br/><br/> 5.12.2 9<br/><br/> 5.12.3 7<br/><br/> 5.12.4 9<br/><br/> 5.12.5 1<br/><br/> 5.12.6 1<br/><br/> 5.13.0 3<br/><br/> 5.13.1 3<br/><br/> 5.13.2 3<br/><br/> 5.13.3 3<br/><br/> 5.13.4 3<br/><br/> 5.13.5 4<br/><br/> 5.13.6 4<br/><br/> 5.13.7 1<br/><br/> 5.13.8 1<br/><br/> 5.13.9 6<br/><br/> 5.13.10 1<br/><br/> 5.13.11 1<br/><br/> 5.14.0 19<br/><br/> 5.14.1 3<br/><br/> 5.14.2 47<br/><br/> 5.14.3 5<br/><br/> 5.14.4 3<br/><br/> 5.14.5 1<br/><br/> 5.15.0 3<br/><br/> 5.15.1 1<br/><br/> 5.15.2 2<br/><br/> 5.15.3 4<br/><br/> 5.15.4 2<br/><br/> 5.15.5 11<br/><br/> 5.15.6 7<br/><br/> 5.15.7 2<br/><br/> 5.15.8 3<br/><br/> 5.15.9 3<br/><br/> 5.15.10 1<br/><br/> 5.16.0 22<br/><br/> 5.16.1 6<br/><br/> 5.16.2 14<br/><br/> 5.16.3 22<br/><br/> 5.16.4 1<br/><br/> 5.17.0 3<br/><br/> 5.17.1 2<br/><br/> 5.17.2 3<br/><br/> 5.17.3 2<br/><br/> 5.17.4 3<br/><br/> 5.17.5 3<br/><br/> 5.17.6 4<br/><br/> 5.17.7 6<br/><br/> 5.17.8 3<br/><br/> 5.17.9 3<br/><br/> 5.17.10 3<br/><br/> 5.17.11 2<br/><br/> 5.17.12 2<br/><br/> 5.18.0 7<br/><br/> 5.18.1 19<br/><br/> 5.18.2 25<br/><br/> 5.18.4 11<br/><br/> 5.19.0 1<br/><br/> 5.19.1 4<br/><br/> 5.19.2 2<br/><br/> 5.19.3 3<br/><br/> 5.19.4 14<br/><br/> 5.19.5 1<br/><br/> 5.19.6 1<br/><br/> 5.19.7 3<br/><br/> 5.19.8 2<br/><br/> 5.19.9 7<br/><br/> 5.19.10 4<br/><br/> 5.19.11 5<br/><br/> 5.20.0 6<br/><br/> 5.20.1 14<br/><br/> 5.20.2 15<br/><br/> 5.20.3 3<br/><br/> 5.21.1 2<br/><br/> 5.21.2 3<br/><br/> 5.21.3 1<br/><br/> 5.21.4 7<br/><br/> 5.21.5 3<br/><br/> 5.21.6 3<br/><br/> 5.21.7 5<br/><br/> 5.21.9 1<br/><br/> 5.21.11 1<br/><br/> 5.22.0 16<br/><br/> 5.22.1 21<br/><br/> 5.22.2 21<br/><br/> 5.23.0 6<br/><br/> 5.23.1 2<br/><br/> 5.23.2 4<br/><br/> 5.23.3 3<br/><br/> 5.23.5 3<br/><br/> 5.23.9 1<br/><br/> 5.24.0 32<br/><br/> 5.24.1 19<br/><br/> 5.24.3 1<br/><br/> 5.24.4 1<br/><br/> 5.25.1 3<br/><br/> 5.25.2 36<br/><br/> 5.25.3 11<br/><br/> 5.25.4 5<br/><br/> 5.25.5 4<br/><br/> 5.25.6 1<br/><br/> 5.25.7 1<br/><br/> 5.25.9 9<br/><br/> 5.25.10 5<br/><br/> 5.25.11 2<br/><br/> 5.26.0 24<br/><br/> 5.26.1 16<br/><br/> 5.26.2 12<br/><br/> 5.27.1 12<br/><br/> 5.27.2 6<br/><br/> 5.27.3 2<br/><br/> 5.27.4 1<br/><br/> 5.27.5 10<br/><br/> 5.27.6 13<br/><br/> 5.27.7 4<br/><br/> 5.27.8 2<br/><br/> 5.27.9 15<br/><br/> 5.27.10 3<br/><br/> 5.27.11 1<br/><br/> 5.28.0 15<br/><br/> 5.28.1 2<br/><br/> 5.29.0 2<br/><br/> 5.29.1 1<br/><br/> 5.29.3 1<br/><br/> 5.29.4 2<br/><br/> 5.29.6 1<br/><br/> 5.29.7 1<br/><br/> 5.29.8 2<br/>-------------------------------------------------------------------------------<br/><br/>Ticket Status By Version<br/><br/> New or Open Resolved<br/><br/>1.0 0 23<br/><br/>5.000 1 9<br/><br/>5.002 0 10<br/><br/>5.003 0 11<br/><br/>5.004 1 13<br/><br/>5.004_00 1 8<br/><br/>5.004_01 1 10<br/><br/>5.004_02 1 8<br/><br/>5.004_03 1 8<br/><br/>5.004_04 1 51<br/><br/>5.004_05 1 13<br/><br/>5.005 1 34<br/><br/>5.005_01 1 12<br/><br/>5.005_02 1 88<br/><br/>5.005_03 4 368<br/><br/>5.005_04 2 11<br/><br/>5.6.0 21 1107<br/><br/>5.6.1 17 623<br/><br/>5.6.2 3 20<br/><br/>5.7.0 2 1487<br/><br/>5.7.1 2 57<br/><br/>5.7.2 4 106<br/><br/>5.8.0 37 637<br/><br/>5.8.1 10 124<br/><br/>5.8.2 11 93<br/><br/>5.8.3 12 124<br/><br/>5.8.4 18 156<br/><br/>5.8.5 8 90<br/><br/>5.8.6 14 90<br/><br/>5.8.7 16 115<br/><br/>5.8.8 58 328<br/><br/>5.8.9 6 34<br/><br/>5.9.0 6 65<br/><br/>5.9.1 4 27<br/><br/>5.9.2 4 37<br/><br/>5.9.3 4 52<br/><br/>5.9.4 4 39<br/><br/>5.9.5 8 44<br/><br/>5.0.1 0 1<br/><br/>5.10.0 72 293<br/><br/>5.10.1 47 145<br/><br/>5.11.0 11 50<br/><br/>5.11.1 3 14<br/><br/>5.11.2 1 17<br/><br/>5.11.3 3 22<br/><br/>5.11.4 2 21<br/><br/>5.11.5 2 17<br/><br/>5.12.0 6 48<br/><br/>5.12.1 9 18<br/><br/>5.12.2 9 49<br/><br/>5.12.3 7 30<br/><br/>5.12.4 9 38<br/><br/>5.12.5 1 5<br/><br/>5.12.6 1 3<br/><br/>5.13.0 3 6<br/><br/>5.13.1 3 9<br/><br/>5.13.2 3 6<br/><br/>5.13.3 3 15<br/><br/>5.13.4 3 19<br/><br/>5.13.5 4 11<br/><br/>5.13.6 4 10<br/><br/>5.13.7 1 10<br/><br/>5.13.8 1 21<br/><br/>5.13.9 6 14<br/><br/>5.13.10 1 17<br/><br/>5.13.11 1 10<br/><br/>5.14.0 19 66<br/><br/>5.14.1 3 25<br/><br/>5.14.2 47 112<br/><br/>5.14.3 5 11<br/><br/>5.14.4 3 14<br/><br/>5.14.5 1 3<br/><br/>5.15.0 3 17<br/><br/>5.15.1 1 31<br/><br/>5.15.2 2 23<br/><br/>5.15.3 4 9<br/><br/>5.15.4 2 12<br/><br/>5.15.5 11 13<br/><br/>5.15.6 7 12<br/><br/>5.15.7 2 25<br/><br/>5.15.8 3 13<br/><br/>5.15.9 3 21<br/><br/>5.15.10 1 3<br/><br/>5.16.0 22 61<br/><br/>5.16.1 6 22<br/><br/>5.16.2 14 32<br/><br/>5.16.3 22 28<br/><br/>5.16.4 1 4<br/><br/>5.17.0 3 15<br/><br/>5.17.1 2 12<br/><br/>5.17.2 3 21<br/><br/>5.17.3 2 13<br/><br/>5.17.4 3 12<br/><br/>5.17.5 3 21<br/><br/>5.17.6 4 13<br/><br/>5.17.7 6 16<br/><br/>5.17.8 3 8<br/><br/>5.17.9 3 14<br/><br/>5.17.10 3 12<br/><br/>5.17.11 2 8<br/><br/>5.17.12 2 5<br/><br/>5.18.0 7 41<br/><br/>5.18.1 19 29<br/><br/>5.18.2 25 37<br/><br/>5.18.3 0 1<br/><br/>5.18.4 11 4<br/><br/>5.18.5 0 1<br/><br/>5.19.0 1 6<br/><br/>5.19.1 4 12<br/><br/>5.19.2 2 10<br/><br/>5.19.3 3 10<br/><br/>5.19.4 14 21<br/><br/>5.19.5 1 7<br/><br/>5.19.6 1 5<br/><br/>5.19.7 3 17<br/><br/>5.19.8 2 11<br/><br/>5.19.9 7 13<br/><br/>5.19.10 4 13<br/><br/>5.19.11 5 8<br/><br/>5.20.0 6 26<br/><br/>5.20.1 14 37<br/><br/>5.20.2 15 31<br/><br/>5.20.3 3 11<br/><br/>5.21.0 0 4<br/><br/>5.21.1 2 17<br/><br/>5.21.2 3 13<br/><br/>5.21.3 1 6<br/><br/>5.21.4 7 61<br/><br/>5.21.5 3 7<br/><br/>5.21.6 3 7<br/><br/>5.21.7 5 37<br/><br/>5.21.8 0 11<br/><br/>5.21.9 1 10<br/><br/>5.21.10 0 5<br/><br/>5.21.11 1 6<br/><br/>5.22.0 16 23<br/><br/>5.22.1 21 27<br/><br/>5.22.2 21 7<br/><br/>5.22.3 0 1<br/><br/>5.22.4 0 1<br/><br/>5.23.0 6 16<br/><br/>5.23.1 2 4<br/><br/>5.23.2 4 6<br/><br/>5.23.3 3 8<br/><br/>5.23.4 0 22<br/><br/>5.23.5 3 16<br/><br/>5.23.6 0 4<br/><br/>5.23.7 0 3<br/><br/>5.23.8 0 4<br/><br/>5.23.9 1 5<br/><br/>5.24.0 32 62<br/><br/>5.24.1 19 26<br/><br/>5.24.2 0 2<br/><br/>5.24.3 1 3<br/><br/>5.24.4 1 2<br/><br/>5.25.0 0 1<br/><br/>5.25.1 3 2<br/><br/>5.25.2 36 11<br/><br/>5.25.3 11 9<br/><br/>5.25.4 5 13<br/><br/>5.25.5 4 7<br/><br/>5.25.6 1 5<br/><br/>5.25.7 1 8<br/><br/>5.25.8 0 3<br/><br/>5.25.9 9 12<br/><br/>5.25.10 5 2<br/><br/>5.25.11 2 4<br/><br/>5.25.12 0 3<br/><br/>5.25.13 0 2<br/><br/>5.26.0 24 25<br/><br/>5.26.1 16 8<br/><br/>5.26.2 12 3<br/><br/>5.26.3 0 0<br/><br/>5.27.0 0 1<br/><br/>5.27.1 12 5<br/><br/>5.27.2 6 3<br/><br/>5.27.3 2 4<br/><br/>5.27.4 1 4<br/><br/>5.27.5 10 4<br/><br/>5.27.6 13 8<br/><br/>5.27.7 4 14<br/><br/>5.27.8 2 7<br/><br/>5.27.9 15 26<br/><br/>5.27.10 3 0<br/><br/>5.27.11 1 2<br/><br/>5.27.12 0 0<br/><br/>5.28.0 15 4<br/><br/>5.28.1 2 0<br/><br/>5.29.0 2 4<br/><br/>5.29.1 1 1<br/><br/>5.29.2 0 0<br/><br/>5.29.3 1 0<br/><br/>5.29.4 2 1<br/><br/>5.29.5 0 0<br/><br/>5.29.6 1 0<br/><br/>5.29.7 1 0<br/><br/>5.29.8 2 0<br/><br/>-------------------------------------------------------------------------------<br/><br/>Requestors with most open tickets<br/><br/>Zefram 69<br/>bulk88 57<br/>Father Chrysostomos 51<br/>Brian Carpenter 49<br/>Nicholas Clark 45<br/>&quot;Ed Avis&quot; 41<br/>l.mai@web.de 39<br/>Sergey Aleynikov 29<br/>Dan Collins 25<br/>Ricardo SIGNES 23<br/><br/>-------------------------------------------------------------------------------<br/><br/> * Numbers<br/> * New Issues<br/> * Overview of Open Issues<br/> * Ticket Status By Version<br/> * Requestors with most open tickets<br/><br/>-------------------------------------------------------------------------------<br/>This page is CPU intensive to create, it will be updated only once every 30<br/>minutes<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253731.html Mon, 18 Feb 2019 16:17:09 +0000 ATOOMIC is doing this month's release - document your commits by Sawyer X Hi all,<br/><br/><br/>Per subject, ATOOMIC (Nicolas R.) is going to do this month&#39;s release (in<br/>two days). If you could please document your commits, that would be very<br/>helpful.<br/><br/><br/>Thanks!<br/><br/>S.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253730.html Mon, 18 Feb 2019 07:48:49 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Tony Cook On Mon, Feb 18, 2019 at 08:55:57AM +1100, Tony Cook wrote:<br/>&gt; which has type Size_t and the block causing the problem:<br/>&gt; <br/>&gt; for (i = 0; i &lt; folds_to_this_cp_count - 1; i++) {<br/>&gt; fold_list = add_cp_to_invlist(fold_list,<br/>&gt; remaining_folds[i]);<br/>&gt; }<br/>&gt; <br/>&gt; (gdb) p folded<br/>&gt; $2 = 8114<br/>&gt; (gdb) p/x folded<br/>&gt; $3 = 0x1fb2<br/><br/>Which you fixed in c2d81cfd08d9a622c639058cd7eb870aa0991937.<br/><br/>Tony<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253729.html Sun, 17 Feb 2019 22:30:20 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Tony Cook On Mon, Feb 18, 2019 at 08:41:21AM +1100, Tony Cook wrote:<br/>&gt; On Sun, Feb 17, 2019 at 08:33:40AM -0800, Karl Williamson via RT wrote:<br/>&gt; &gt; Hugo is right. The data looks like UTF-16, and is legal as that encoding.<br/>&gt; &gt; Rejecting this ticket<br/>&gt; <br/>&gt; Where&#39;s it picking up the closing / for the regexp?<br/><br/>Ahh, nevermind, it&#39;s C&lt;&lt; 0 / m\0...\0 &gt;&gt;.<br/><br/>Though with a -DDEBUGGING build:<br/><br/>$ ./perl -v | grep version<br/>This is perl 5, version 29, subversion 8 (v5.29.8 (v5.29.7-97-g8ff14b702b)) built for x86_64-linux<br/>$ ./perl ../133851.pl <br/>Segmentation fault<br/>...<br/>Program received signal SIGSEGV, Segmentation fault.<br/>0x00005555556d17e7 in S_regclass (pRExC_state=0x7fffffffdd20, <br/> flagp=0x7fffffffd414, depth=5, stop_at_1=false, allow_multi_folds=true, <br/> silence_non_portable=false, strict=false, optimizable=true, <br/> ret_invlist=0x0) at regcomp.c:18632<br/>18632 fold_list = add_cp_to_invlist(fold_list,<br/>(gdb) bt<br/>#0 0x00005555556d17e7 in S_regclass (pRExC_state=0x7fffffffdd20, <br/> flagp=0x7fffffffd414, depth=5, stop_at_1=false, allow_multi_folds=true, <br/> silence_non_portable=false, strict=false, optimizable=true, <br/> ret_invlist=0x0) at regcomp.c:18632<br/>#1 0x00005555556af993 in S_regatom (pRExC_state=0x7fffffffdd20, <br/> flagp=0x7fffffffd414, depth=4) at regcomp.c:13232<br/>#2 0x00005555556a95b4 in S_regpiece (pRExC_state=0x7fffffffdd20, <br/> flagp=0x7fffffffd530, depth=3) at regcomp.c:12472<br/>#3 0x00005555556a8e96 in S_regbranch (pRExC_state=0x7fffffffdd20, <br/> flagp=0x7fffffffd5d4, first=1, depth=2) at regcomp.c:12390<br/>#4 0x00005555556a6762 in S_reg (pRExC_state=0x7fffffffdd20, paren=0, <br/> flagp=0x7fffffffda58, depth=1) at regcomp.c:12111<br/>#5 0x0000555555689ecd in Perl_re_op_compile (patternp=0x0, pat_count=1, <br/> expr=0x555555d4c828, eng=0x555555d17500 &lt;PL_core_reg_engine&gt;, old_re=0x0, <br/> is_bare_re=0x0, orig_rx_flags=0, pm_flags=0) at regcomp.c:7667<br/>#6 0x00005555555a62d5 in Perl_pmruntime (o=0x555555d4c868, <br/> expr=0x555555d4c828, repl=0x0, flags=1, floor=0) at op.c:7094<br/>#7 0x000055555565d140 in Perl_yyparse (gramtype=258) at perly.y:1228<br/>#8 0x00005555555d86c9 in S_parse_body (env=0x0, <br/> xsinit=0x55555558d373 &lt;xs_init&gt;) at perl.c:2506<br/>#9 0x00005555555d6984 in perl_parse (my_perl=0x555555d22010, <br/> xsinit=0x55555558d373 &lt;xs_init&gt;, argc=2, argv=0x7fffffffe868, env=0x0)<br/> at perl.c:1797<br/>---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit---<br/>#10 0x000055555558d2b6 in main (argc=2, argv=0x7fffffffe868, <br/> env=0x7fffffffe880) at perlmain.c:121<br/>(gdb) p folds_to_this_cp_count<br/>$1 = 0<br/><br/>which has type Size_t and the block causing the problem:<br/><br/> for (i = 0; i &lt; folds_to_this_cp_count - 1; i++) {<br/> fold_list = add_cp_to_invlist(fold_list,<br/> remaining_folds[i]);<br/> }<br/><br/>(gdb) p folded<br/>$2 = 8114<br/>(gdb) p/x folded<br/>$3 = 0x1fb2<br/><br/>Tony<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253728.html Sun, 17 Feb 2019 21:56:07 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Tony Cook On Sun, Feb 17, 2019 at 08:33:40AM -0800, Karl Williamson via RT wrote:<br/>&gt; Hugo is right. The data looks like UTF-16, and is legal as that encoding.<br/>&gt; Rejecting this ticket<br/><br/>Where&#39;s it picking up the closing / for the regexp?<br/><br/>Tony<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253727.html Sun, 17 Feb 2019 21:41:37 +0000 [perl #133851] Tokenizer accepts garbage input by Karl Williamson via RT Hugo is right. The data looks like UTF-16, and is legal as that encoding.<br/>Rejecting this ticket<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133851<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253726.html Sun, 17 Feb 2019 16:33:48 +0000 [perl #133851] Tokenizer accepts garbage input by Hugo van der Sanden via RT On Sat, 16 Feb 2019 19:06:47 -0800, public@khwilliamson.com wrote:<br/>&gt; &gt;&gt;&gt; The generated .pl looks like:<br/>&gt; &gt;&gt;&gt;<br/>&gt; &gt;&gt;&gt; od -t x1 test0084.pl<br/>&gt; &gt;&gt;&gt; 0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00<br/>&gt; &gt;&gt;&gt; 0000020<br/>&gt; &gt; <br/>&gt; &gt; Notice all the NULs.&Acirc;&nbsp; This string is getting turned into something <br/>&gt; &gt; almost completely different, with somehow it looking like<br/>&gt; &gt; m/[\x{\xE3\x80\xB0}\x{\xE1\xBE\xB2}<br/>&gt; &gt; <br/>&gt; &gt; Most of those bytes aren&#39;t in the original, The inital 0x30 (a digit 0) <br/>&gt; &gt; is gone, etc. etc.<br/>&gt; <br/>&gt; Actually, I see that 3030 and 1fb2 are in there if the string is <br/>&gt; interpreted as UTF-8, but how that&#39;s happening I don&#39;t know.<br/><br/>I think the input is getting detected as UCS-2 because of the pattern of nuls in the initial bytes. I don&#39;t recall OTTOMH where that happens, but it&#39;s probably in the same place as BOM detection.<br/><br/>Hugo<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133851<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253725.html Sun, 17 Feb 2019 10:11:51 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Karl Williamson On 2/16/19 7:14 PM, Karl Williamson wrote: <br/>&gt; On 2/16/19 5:12 PM, James E Keenan via RT wrote: <br/>&gt;&gt; On Sat, 16 Feb 2019 20:45:24 GMT, public@khwilliamson.com wrote: <br/>&gt;&gt;&gt; This is a bug report for perl from khw@khw-xps-8930.(none), <br/>&gt;&gt;&gt; generated with the help of perlbug 1.41 running under perl 5.29.8. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; ----------------------------------------------------------------- <br/>&gt;&gt;&gt; This code should result in the parser rejecting the program, as it is <br/>&gt;&gt;&gt; garbage, but instead it gets interpreted as valid input. <br/>&gt;&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; Can you elaborate as to why the parser should reject this?&nbsp; (I suspect <br/>&gt;&gt; that few readers know much about that area.) <br/>&gt;&gt; <br/>&gt;&gt;&gt; echo &quot;MAAvAG0AAABbADAwsh8AAA==&quot; | base64 -d | tee test0084.pl | ./perl <br/>&gt;&gt;&gt; -Dr test0084.pl <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; The generated .pl looks like: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; od -t x1 test0084.pl <br/>&gt;&gt;&gt; 0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00 <br/>&gt;&gt;&gt; 0000020 <br/>&gt; <br/>&gt; Notice all the NULs.&nbsp; This string is getting turned into something <br/>&gt; almost completely different, with somehow it looking like <br/>&gt; m/[\x{\xE3\x80\xB0}\x{\xE1\xBE\xB2} <br/>&gt; <br/>&gt; Most of those bytes aren&#39;t in the original, The inital 0x30 (a digit 0) <br/>&gt; is gone, etc. etc. <br/> <br/>Actually, I see that 3030 and 1fb2 are in there if the string is <br/>interpreted as UTF-8, but how that&#39;s happening I don&#39;t know. <br/>&gt;&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; When I run the generated perl program with a debugging perl built at <br/>&gt;&gt; blead, I get: <br/>&gt;&gt; <br/>&gt;&gt; ##### <br/>&gt;&gt; $ ./bin/perl -Ilib -Dr test0084.pl <br/>&gt;&gt; Compiling REx &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt;&gt; Wide character in print at /home/jkeenan/learn/perl/p5p/test0084.pl <br/>&gt;&gt; line 1. <br/>&gt;&gt; Unmatched [ in regex; marked by &lt;-- HERE in m/[ &lt;-- HERE &#x3030;&#x1FB2;/ at <br/>&gt;&gt; test0084.pl line 1. <br/>&gt;&gt; Freeing REx: &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt;&gt; ##### <br/>&gt;&gt; <br/>&gt;&gt; Is that relevant to the bug? <br/>&gt;&gt; <br/>&gt;&gt; Thank you very much. <br/>&gt;&gt; <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253724.html Sun, 17 Feb 2019 03:06:41 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Karl Williamson On 2/16/19 5:12 PM, James E Keenan via RT wrote: <br/>&gt; On Sat, 16 Feb 2019 20:45:24 GMT, public@khwilliamson.com wrote: <br/>&gt;&gt; This is a bug report for perl from khw@khw-xps-8930.(none), <br/>&gt;&gt; generated with the help of perlbug 1.41 running under perl 5.29.8. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; ----------------------------------------------------------------- <br/>&gt;&gt; This code should result in the parser rejecting the program, as it is <br/>&gt;&gt; garbage, but instead it gets interpreted as valid input. <br/>&gt;&gt; <br/>&gt; <br/>&gt; Can you elaborate as to why the parser should reject this? (I suspect that few readers know much about that area.) <br/>&gt; <br/>&gt;&gt; echo &quot;MAAvAG0AAABbADAwsh8AAA==&quot; | base64 -d | tee test0084.pl | ./perl <br/>&gt;&gt; -Dr test0084.pl <br/>&gt;&gt; <br/>&gt;&gt; The generated .pl looks like: <br/>&gt;&gt; <br/>&gt;&gt; od -t x1 test0084.pl <br/>&gt;&gt; 0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00 <br/>&gt;&gt; 0000020 <br/> <br/>Notice all the NULs. This string is getting turned into something <br/>almost completely different, with somehow it looking like <br/>m/[\x{\xE3\x80\xB0}\x{\xE1\xBE\xB2} <br/> <br/>Most of those bytes aren&#39;t in the original, The inital 0x30 (a digit 0) <br/>is gone, etc. etc. <br/>&gt;&gt; <br/>&gt; <br/>&gt; When I run the generated perl program with a debugging perl built at blead, I get: <br/>&gt; <br/>&gt; ##### <br/>&gt; $ ./bin/perl -Ilib -Dr test0084.pl <br/>&gt; Compiling REx &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt; Wide character in print at /home/jkeenan/learn/perl/p5p/test0084.pl line 1. <br/>&gt; Unmatched [ in regex; marked by &lt;-- HERE in m/[ &lt;-- HERE &#x3030;&#x1FB2;/ at test0084.pl line 1. <br/>&gt; Freeing REx: &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt; ##### <br/>&gt; <br/>&gt; Is that relevant to the bug? <br/>&gt; <br/>&gt; Thank you very much. <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253723.html Sun, 17 Feb 2019 02:15:17 +0000 Re: [perl #133851] Tokenizer accepts garbage input by Karl Williamson On 2/16/19 5:12 PM, James E Keenan via RT wrote: <br/>&gt; On Sat, 16 Feb 2019 20:45:24 GMT, public@khwilliamson.com wrote: <br/>&gt;&gt; This is a bug report for perl from khw@khw-xps-8930.(none), <br/>&gt;&gt; generated with the help of perlbug 1.41 running under perl 5.29.8. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; ----------------------------------------------------------------- <br/>&gt;&gt; This code should result in the parser rejecting the program, as it is <br/>&gt;&gt; garbage, but instead it gets interpreted as valid input. <br/>&gt;&gt; <br/>&gt; <br/>&gt; Can you elaborate as to why the parser should reject this? (I suspect that few readers know much about that area.) <br/>&gt; <br/>&gt;&gt; echo &quot;MAAvAG0AAABbADAwsh8AAA==&quot; | base64 -d | tee test0084.pl | ./perl <br/>&gt;&gt; -Dr test0084.pl <br/>&gt;&gt; <br/>&gt;&gt; The generated .pl looks like: <br/>&gt;&gt; <br/>&gt;&gt; od -t x1 test0084.pl <br/>&gt;&gt; 0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00 <br/>&gt;&gt; 0000020 <br/>&gt;&gt; <br/>&gt; <br/>&gt; When I run the generated perl program with a debugging perl built at blead, I get: <br/>&gt; <br/>&gt; ##### <br/>&gt; $ ./bin/perl -Ilib -Dr test0084.pl <br/>&gt; Compiling REx &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt; Wide character in print at /home/jkeenan/learn/perl/p5p/test0084.pl line 1. <br/>&gt; Unmatched [ in regex; marked by &lt;-- HERE in m/[ &lt;-- HERE &#x3030;&#x1FB2;/ at test0084.pl line 1. <br/>&gt; Freeing REx: &quot;[%x{3030}%x{1fb2}&quot; <br/>&gt; ##### <br/>&gt; <br/>&gt; Is that relevant to the bug? <br/> <br/>No <br/> <br/>&gt; <br/>&gt; Thank you very much. <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253722.html Sun, 17 Feb 2019 02:10:17 +0000 [perl #133851] Tokenizer accepts garbage input by James E Keenan via RT On Sat, 16 Feb 2019 20:45:24 GMT, public@khwilliamson.com wrote:<br/>&gt; This is a bug report for perl from khw@khw-xps-8930.(none),<br/>&gt; generated with the help of perlbug 1.41 running under perl 5.29.8.<br/>&gt; <br/>&gt; <br/>&gt; -----------------------------------------------------------------<br/>&gt; This code should result in the parser rejecting the program, as it is<br/>&gt; garbage, but instead it gets interpreted as valid input.<br/>&gt; <br/><br/>Can you elaborate as to why the parser should reject this? (I suspect that few readers know much about that area.)<br/><br/>&gt; echo &quot;MAAvAG0AAABbADAwsh8AAA==&quot; | base64 -d | tee test0084.pl | ./perl<br/>&gt; -Dr test0084.pl<br/>&gt; <br/>&gt; The generated .pl looks like:<br/>&gt; <br/>&gt; od -t x1 test0084.pl<br/>&gt; 0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00<br/>&gt; 0000020<br/>&gt; <br/><br/>When I run the generated perl program with a debugging perl built at blead, I get:<br/><br/>#####<br/>$ ./bin/perl -Ilib -Dr test0084.pl <br/>Compiling REx &quot;[%x{3030}%x{1fb2}&quot;<br/>Wide character in print at /home/jkeenan/learn/perl/p5p/test0084.pl line 1.<br/>Unmatched [ in regex; marked by &lt;-- HERE in m/[ &lt;-- HERE &atilde;&#128;&deg;&aacute;&frac34;&sup2;/ at test0084.pl line 1.<br/>Freeing REx: &quot;[%x{3030}%x{1fb2}&quot;<br/>#####<br/><br/>Is that relevant to the bug?<br/><br/>Thank you very much.<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=133851<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253721.html Sun, 17 Feb 2019 00:12:34 +0000 [perl #133851] Tokenizer accepts garbage input by karl williamson # New Ticket Created by karl williamson <br/># Please include the string: [perl #133851]<br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=133851 &gt;<br/><br/><br/>This is a bug report for perl from khw@khw-xps-8930.(none),<br/>generated with the help of perlbug 1.41 running under perl 5.29.8.<br/><br/><br/>-----------------------------------------------------------------<br/>This code should result in the parser rejecting the program, as it is<br/>garbage, but instead it gets interpreted as valid input.<br/><br/>echo &quot;MAAvAG0AAABbADAwsh8AAA==&quot; | base64 -d | tee test0084.pl | ./perl <br/>-Dr test0084.pl<br/><br/>The generated .pl looks like:<br/><br/>od -t x1 test0084.pl<br/>0000000 30 00 2f 00 6d 00 00 00 5b 00 30 30 b2 1f 00 00<br/>0000020<br/>-----------------------------------------------------------------<br/>---<br/>Flags:<br/> category=core<br/> severity=medium<br/>---<br/>Site configuration information for perl 5.29.8:<br/><br/>Configured by khw at Sat Feb 16 12:51:23 MST 2019.<br/><br/>Summary of my perl5 (revision 5 version 29 subversion 8) configuration:<br/> Commit id: 2cbd034e1cb70cf9cb1ae2a83967a24dd90ecc53<br/> Platform:<br/> osname=linux<br/> osvers=4.15.0-45-generic<br/> archname=x86_64-linux-thread-multi-ld<br/> uname=&#39;linux khw-xps-8930 4.15.0-45-generic #48-ubuntu smp tue jan <br/>29 16:28:13 utc 2019 x86_64 x86_64 x86_64 gnulinux &#39;<br/> config_args=&#39;-des -Uversiononly -Dprefix=/home/khw/blead -Dusedevel <br/>-A&#39;optimize=-ggdb3&#39; -A&#39;optimize=-O0&#39; -Accflags=&#39;-Wno-deprecated&#39; <br/>-Dman1dir=none -Dman3dir=none -Dcc=g++ -DDEBUGGING -Dusemorebits <br/>-Dusecbacktrace -Dusethreads&#39;<br/> hint=recommended<br/> useposix=true<br/> d_sigaction=define<br/> useithreads=define<br/> usemultiplicity=define<br/> use64bitint=define<br/> use64bitall=define<br/> uselongdouble=define<br/> usemymalloc=n<br/> default_inc_excludes_dot=define<br/> bincompat5005=undef<br/> Compiler:<br/> cc=&#39;g++&#39;<br/> ccflags =&#39;-D_REENTRANT -D_GNU_SOURCE -Wno-deprecated -fwrapv <br/>-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong <br/>-I/usr/local/include -DUSE_C_BACKTRACE -g -D_LARGEFILE_SOURCE <br/>-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2&#39;<br/> optimize=&#39;-O2 -ggdb3 -O0&#39;<br/> cppflags=&#39;-D_REENTRANT -D_GNU_SOURCE -Wno-deprecated -fwrapv <br/>-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong <br/>-I/usr/local/include&#39;<br/> ccversion=&#39;&#39;<br/> gccversion=&#39;7.3.0&#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;long double&#39;<br/> nvsize=16<br/> Off_t=&#39;off_t&#39;<br/> lseeksize=8<br/> alignbytes=16<br/> prototype=define<br/> Linker and Libraries:<br/> ld=&#39;g++&#39;<br/> ldflags =&#39; -fstack-protector-strong -L/usr/local/lib&#39;<br/> libpth=/usr/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 <br/>/usr/include/c++/7/backward /usr/local/lib <br/>/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed <br/>/usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib <br/>/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib<br/> libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc<br/> perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc<br/> libc=libc-2.27.so<br/> so=so<br/> useshrplib=false<br/> libperl=libperl.a<br/> gnulibc_version=&#39;2.27&#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 -ggdb3 -O0 -L/usr/local/lib <br/>-fstack-protector-strong&#39;<br/><br/><br/>---<br/>@INC for perl 5.29.8:<br/> /home/khw/blead/lib/perl5/site_perl/5.29.8/x86_64-linux-thread-multi-ld<br/> /home/khw/blead/lib/perl5/site_perl/5.29.8<br/> /home/khw/blead/lib/perl5/5.29.8/x86_64-linux-thread-multi-ld<br/> /home/khw/blead/lib/perl5/5.29.8<br/> /home/khw/blead/lib/perl5/site_perl/5.29.7<br/> /home/khw/blead/lib/perl5/site_perl/5.29.6<br/> /home/khw/blead/lib/perl5/site_perl/5.29.5<br/> /home/khw/blead/lib/perl5/site_perl/5.29.4<br/> /home/khw/blead/lib/perl5/site_perl/5.29.3<br/> /home/khw/blead/lib/perl5/site_perl/5.29.2<br/> /home/khw/blead/lib/perl5/site_perl/5.29.1<br/> /home/khw/blead/lib/perl5/site_perl/5.29.0<br/> /home/khw/blead/lib/perl5/site_perl/5.28.0<br/> /home/khw/blead/lib/perl5/site_perl/5.27.11<br/> /home/khw/blead/lib/perl5/site_perl/5.27.10<br/> /home/khw/blead/lib/perl5/site_perl/5.27.9<br/> /home/khw/blead/lib/perl5/site_perl/5.27.8<br/> /home/khw/blead/lib/perl5/site_perl/5.27.7<br/> /home/khw/blead/lib/perl5/site_perl/5.27.6<br/> /home/khw/blead/lib/perl5/site_perl/5.27.5<br/> /home/khw/blead/lib/perl5/site_perl/5.27.4<br/> /home/khw/blead/lib/perl5/site_perl/5.27.3<br/> /home/khw/blead/lib/perl5/site_perl/5.27.2<br/> /home/khw/blead/lib/perl5/site_perl/5.27.1<br/> /home/khw/blead/lib/perl5/site_perl/5.27.0<br/> /home/khw/blead/lib/perl5/site_perl/5.26.0<br/> /home/khw/blead/lib/perl5/site_perl/5.25.12<br/> /home/khw/blead/lib/perl5/site_perl/5.25.11<br/> /home/khw/blead/lib/perl5/site_perl/5.25.10<br/> /home/khw/blead/lib/perl5/site_perl/5.25.9<br/> /home/khw/blead/lib/perl5/site_perl/5.25.8<br/> /home/khw/blead/lib/perl5/site_perl/5.25.7<br/> /home/khw/blead/lib/perl5/site_perl/5.25.6<br/> /home/khw/blead/lib/perl5/site_perl/5.25.5<br/> /home/khw/blead/lib/perl5/site_perl/5.25.4<br/> /home/khw/blead/lib/perl5/site_perl/5.25.3<br/> /home/khw/blead/lib/perl5/site_perl/5.25.2<br/> /home/khw/blead/lib/perl5/site_perl/5.25.1<br/> /home/khw/blead/lib/perl5/site_perl/5.24.0<br/> /home/khw/blead/lib/perl5/site_perl/5.23.10<br/> /home/khw/blead/lib/perl5/site_perl/5.23.9<br/> /home/khw/blead/lib/perl5/site_perl/5.23.8<br/> /home/khw/blead/lib/perl5/site_perl/5.23.7<br/> /home/khw/blead/lib/perl5/site_perl/5.23.6<br/> /home/khw/blead/lib/perl5/site_perl/5.23.5<br/> /home/khw/blead/lib/perl5/site_perl/5.23.4<br/> /home/khw/blead/lib/perl5/site_perl/5.23.3<br/> /home/khw/blead/lib/perl5/site_perl/5.23.2<br/> /home/khw/blead/lib/perl5/site_perl/5.23.1<br/> /home/khw/blead/lib/perl5/site_perl/5.23.0<br/> /home/khw/blead/lib/perl5/site_perl/5.22.0<br/> /home/khw/blead/lib/perl5/site_perl/5.21.12<br/> /home/khw/blead/lib/perl5/site_perl/5.21.11<br/> /home/khw/blead/lib/perl5/site_perl/5.21.10<br/> /home/khw/blead/lib/perl5/site_perl/5.21.9<br/> /home/khw/blead/lib/perl5/site_perl/5.21.8<br/> /home/khw/blead/lib/perl5/site_perl/5.21.7<br/> /home/khw/blead/lib/perl5/site_perl/5.21.6<br/> /home/khw/blead/lib/perl5/site_perl/5.21.5<br/> /home/khw/blead/lib/perl5/site_perl/5.21.4<br/> /home/khw/blead/lib/perl5/site_perl/5.21.3<br/> /home/khw/blead/lib/perl5/site_perl/5.21.2<br/> /home/khw/blead/lib/perl5/site_perl/5.21.1<br/> /home/khw/blead/lib/perl5/site_perl/5.20.0<br/> /home/khw/blead/lib/perl5/site_perl/5.19.12<br/> /home/khw/blead/lib/perl5/site_perl/5.19.11<br/> /home/khw/blead/lib/perl5/site_perl/5.19.10<br/> /home/khw/blead/lib/perl5/site_perl<br/><br/>---<br/>Environment for perl 5.29.8:<br/> HOME=/home/khw<br/> LANG=en_US.UTF-8<br/> LANGUAGE=en<br/> LD_LIBRARY_PATH (unset)<br/> LOGDIR (unset)<br/><br/>PATH=/usr/lib/ccache:/home/khw/bin:/home/khw/perl5/perlbrew/bin:/home/khw/print/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/games:/usr/local/games:/snap/bin:/home/khw/iands/www:/home/khw/cxoffice/bin<br/> PERL5OPT=-w<br/> PERL_BADLANG (unset)<br/> PERL_DIFF_TOOL=wgdiff<br/> PERL_POD_PEDANTIC=1<br/> SHELL=/usr/bin/ksh<br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253720.html Sat, 16 Feb 2019 20:45:28 +0000 [perl #133770] null pointer dereference in S_regclass() by Karl Williamson via RT On Sat, 16 Feb 2019 11:48:41 -0800, khw wrote:<br/>&gt; Now fixed by<br/>&gt; <br/>&gt; commit c2d81cfd08d9a622c639058cd7eb870aa0991937<br/>&gt; Author: Karl Williamson &lt;khw@cpan.org&gt;<br/>&gt; Date: Sat Feb 16 11:11:59 2019 -0700<br/>&gt; <br/>&gt; PATCH: [perl #133770] null pointer dereference in S_regclass()<br/>&gt; <br/>&gt; The failing case can be reduced to<br/>&gt; <br/>&gt; qr/\x{100}[\x{3030}\x{1fb2}/<br/>&gt; <br/>&gt; (It only happens on UTF-8 patterns).<br/>&gt; <br/>&gt; The bottom line is that it was assuming that there was at least one<br/>&gt; character that folded to 1fb2 besides itself, even though the function<br/>&gt; call said there weren&#39;t any such. The solution is to pay attention to<br/>&gt; the function return value.<br/>&gt; <br/>&gt; I incorporated Hugo&#39;s++ patch as part of this one.<br/>&gt; <br/>&gt; However, the original test case should never have gotten this far.<br/>&gt; The<br/>&gt; parser is getting passed garbage, and instead of croaking, it is<br/>&gt; somehow<br/>&gt; interpreting it as valid and calling the regex compiler. I will file<br/>&gt; a<br/>&gt; ticket about that.<br/><br/>Note that this bug was introduced in the current 5.29 release, so should not go into the 5.30 perldelta, and hence is marked as &#39;resolved&#39;<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: resolved<br/>https://rt.perl.org/Ticket/Display.html?id=133770<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253719.html Sat, 16 Feb 2019 19:49:51 +0000 [perl #133770] null pointer dereference in S_regclass() by Karl Williamson via RT Now fixed by<br/><br/>commit c2d81cfd08d9a622c639058cd7eb870aa0991937<br/> Author: Karl Williamson &lt;khw@cpan.org&gt;<br/> Date: Sat Feb 16 11:11:59 2019 -0700<br/> <br/> PATCH: [perl #133770] null pointer dereference in S_regclass()<br/> <br/> The failing case can be reduced to<br/> <br/> qr/\x{100}[\x{3030}\x{1fb2}/<br/> <br/> (It only happens on UTF-8 patterns).<br/> <br/> The bottom line is that it was assuming that there was at least one<br/> character that folded to 1fb2 besides itself, even though the function<br/> call said there weren&#39;t any such. The solution is to pay attention to<br/> the function return value.<br/> <br/> I incorporated Hugo&#39;s++ patch as part of this one.<br/> <br/> However, the original test case should never have gotten this far. The<br/> parser is getting passed garbage, and instead of croaking, it is somehow<br/> interpreting it as valid and calling the regex compiler. I will file a<br/> ticket about that.<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133770<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253718.html Sat, 16 Feb 2019 19:48:48 +0000 Re: RFC: Use ptrdiff_t instead of SSize_t by Karl Williamson On 8/3/18 11:30 PM, Karl Williamson wrote: <br/>&gt; On 08/03/2018 04:48 PM, Tomasz Konojacki wrote: <br/>&gt;&gt; <br/>&gt;&gt; On Tue, 17 Jul 2018 14:29:49 +1000 <br/>&gt;&gt; Tony Cook &lt;tony@develop-help.com&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt;&gt; On Mon, Jul 16, 2018 at 06:12:25PM -0600, Karl Williamson wrote: <br/>&gt;&gt;&gt;&gt; I stumbled upon this detail in stack overflow: <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; &quot;The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2013 <br/>&gt;&gt;&gt;&gt; Edition, <br/>&gt;&gt;&gt;&gt; description of &lt;sys/types.h&gt; says: <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; The type ssize_t is capable of storing values at least in the range <br/>&gt;&gt;&gt;&gt; [-1, <br/>&gt;&gt;&gt;&gt; SSIZE_MAX].&quot; <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; https://stackoverflow.com/questions/8649018/what-is-the-difference-between-ssize-t-and-ptrdiff-t <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; That means it doesn&#39;t necessarily work for the difference between <br/>&gt;&gt;&gt;&gt; two ptrs, <br/>&gt;&gt;&gt;&gt; which is something I have used it for. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; But ptrdiff_t must be capable of storing any such difference.&nbsp; Also, <br/>&gt;&gt;&gt;&gt; any <br/>&gt;&gt;&gt;&gt; object&#39;s size can be expressed as the difference between its ending and <br/>&gt;&gt;&gt;&gt; starting pointers, so ptrdiff_t must be able to store anything ssize_t, <br/>&gt;&gt;&gt;&gt; STRLEN or plain size_t can store, as well. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Not exactly, ptrdiff_t is signed while STRLEN and size_t are unsigned. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; The obvious difference that STRLEN/size_t can store larger positive <br/>&gt;&gt;&gt; numbers than ptrdiff_t, but the more subtle difference is that <br/>&gt;&gt;&gt; overflow for unsigned integer types is well defined, while it causes <br/>&gt;&gt;&gt; undefined behaviour for signed integer types. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Tony <br/>&gt;&gt; <br/>&gt;&gt; C11 says: <br/>&gt;&gt; <br/>&gt;&gt;&gt; When two pointers are subtracted, both shall point to elements of the <br/>&gt;&gt;&gt; same array object, <br/>&gt;&gt;&gt; or one past the last element of the array object; the result is the <br/>&gt;&gt;&gt; difference of the <br/>&gt;&gt;&gt; subscripts of the two array elements. The size of the result is <br/>&gt;&gt;&gt; implementation-defined, <br/>&gt;&gt;&gt; and its type (a signed integer type) is ptrdiff_t defined in the <br/>&gt;&gt;&gt; &lt;stddef.h&gt; header. <br/>&gt;&gt;&gt; If the result is not representable in an object of that type, the <br/>&gt;&gt;&gt; behavior is undefined. <br/>&gt;&gt; <br/>&gt;&gt; There are many ways to interpret this passage, but according to (most?) <br/>&gt;&gt; C compilers developers, it means that no object can be larger than <br/>&gt;&gt; PTRDIFF_MAX. For example, gcc&#39;s optimizer assummes that strlen() will <br/>&gt;&gt; never return anything larger than PTRDIFF_MAX [1]. <br/>&gt;&gt; <br/>&gt;&gt; There&#39;s also a blogpost[2] on this topic, which IMO is a very <br/>&gt;&gt; interesting read. <br/>&gt;&gt; <br/>&gt;&gt; If gcc and clang can assume that all objects won&#39;t be larger than <br/>&gt;&gt; PTRDIFF_MAX, so can we. Also, in practice, ssize_t and ptrdiff_t on most <br/>&gt;&gt; (all?) platforms are defined as exactly the same type. <br/>&gt;&gt; <br/>&gt;&gt; BTW, the fact that compilers assume that objects can&#39;t be larger than <br/>&gt;&gt; PTRDIFF_MAX has very dangerous implications on 32-bit platforms. Is it <br/>&gt;&gt; possible to create string longer than PTRDIFF_MAX on 32-bit perls?. It <br/>&gt;&gt; shouldn&#39;t be allowed. <br/>&gt; <br/>&gt; The C standard is poor here.&nbsp; One reading is that that you can have <br/>&gt; objects that are bigger than PTRDIFF_MAX, and if you happen to subtract <br/>&gt; pointers from the wrong two elements, the results are undefined, whereas <br/>&gt; subtracting from the right two ones gives valid defined results.&nbsp; And <br/>&gt; there is no convenient way to know whether you have a valid result or <br/>&gt; not.&nbsp;&nbsp; I don&#39;t like this phrase, but it seems apt in this case: &quot;Down <br/>&gt; this path lies madness&quot;.&nbsp; So of course, a practical implementation can&#39;t <br/>&gt; have that some times the results are defined and some times not, for a <br/>&gt; valid object.&nbsp; That means that a practical object can&#39;t be larger than <br/>&gt; PTRDIFF_MAX.&nbsp; The implication is that SIZE_MAX really shouldn&#39;t be <br/>&gt; larger than PTRDIFF_MAX (though in my Linux gcc box it is twice the <br/>&gt; size), and that is hard to do since size_t is unsigned and ptrdiff_t is <br/>&gt; signed.&nbsp; The C99 rationale suggests this dilemma can be solved by making <br/>&gt; ptrdiff_t &quot;long long&quot;. <br/>&gt; <br/>&gt; I think Tomasz put it very well when he said that if gcc and clang <br/>&gt; assume something, then so can we. <br/>&gt; <br/>&gt; I don&#39;t think we should be using ssize_t.&nbsp; On most platforms, it doesn&#39;t <br/>&gt; matter, but on some it could, and ptrdiff_t is the safer choice. <br/>&gt;&gt; <br/>&gt;&gt; [1] - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78153 <br/>&gt;&gt; [2] - https://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/ <br/>&gt;&gt; <br/>&gt; <br/> <br/>For now, I added code to prevent mallocs larger than PTRDIFF_MAX. <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253717.html Sat, 16 Feb 2019 19:18:11 +0000 [perl #133767] assertion failure in regnode_offset S_regclass() by Karl Williamson via RT This is fixed by 75451d8cc625c69a543f2bacf2312d369f8855ae<br/><br/>Note that this bug was introduced in the 5.29 series, so need not be in the 5.30 perldelta, and is marked as resolved rather than pending release<br/>-- <br/>Karl Williamson<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133767<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253716.html Sat, 16 Feb 2019 17:11:28 +0000 Re: Comment: Restricting POSIX character classes to ASCII by Karl Williamson On 1/21/19 12:02 PM, Thomas (HFM) Wyant wrote:<br/>&gt; Dear Perl Porters,<br/>&gt; <br/>&gt; <br/>&gt; While researching correspondence re my recent blog post on sanitizing <br/>&gt; numeric input <br/>&gt; (http://blogs.perl.org/users/tom_wyant/2019/01/untrusted-numeric-input.html) <br/>&gt; I discovered the following in perlrecharclass as the last paragraph in <br/>&gt; &quot;POSIX Character Classes&quot;:<br/>&gt; <br/>&gt; <br/>&gt; It is proposed to change this behavior in a future release of Perl so that<br/>&gt; whether or not Unicode rules are in effect would not change the behavior:<br/>&gt; Outside of locale, the POSIX classes would behave like their ASCII-range<br/>&gt; counterparts. If you wish to comment on this proposal, send email to<br/>&gt; &quot;perl5-porters@perl.org&quot;.<br/>&gt; <br/>&gt; <br/>&gt; In response to this offer, I would like to share the following thoughts:<br/>&gt; <br/>&gt; <br/>&gt; * Is this still the plan? If this is no longer the plan, the paragraph <br/>&gt; should be removed. If it is still the plan, I believe more publicity <br/>&gt; would be helpful -- say, on https://www.perl.com/. I was able to track <br/>&gt; this paragraph as far back as Perl 5.14.0, May 2011, so if it is still <br/>&gt; the plan it has been hanging fire for almost 8 years.<br/><br/>This is not the plan anymore, and I have removed the paragraph in <br/>4f5c9941bb6f93a967e4cc3ef19c9d39351f0ad3<br/>&gt; <br/>&gt; <br/>&gt; * I would prefer that the referred-to change NOT be made. We already <br/>&gt; have a good half-dozen ways to deal with the &quot;restrict to ASCII range&quot; <br/>&gt; problem, most of which are Perl-version-dependent. The justification for <br/>&gt; adding yet another is unclear to me. Specifically, what does it get me <br/>&gt; that &#39;use re /a;&#39; (introduced in 5.13.10) does not?<br/>&gt; <br/>&gt; <br/>&gt; * If there are compelling reasons to pursue this, I would appreciate it <br/>&gt; if those reasons were made explicit.<br/>&gt; <br/>&gt; <br/>&gt; * If this change is pursued, please try to do it in a way that minimizes <br/>&gt; the need for Perl code to be aware of the version of Perl it runs under. <br/>&gt; This seems to me to mean tying it to &#39;use 5.xxxx;&#39;, but there may well <br/>&gt; be better ways.<br/>&gt; <br/>&gt; <br/>&gt; With thanks for shepherding Perl into its 4th decade (!!!)<br/>&gt; <br/>&gt; <br/>&gt; Tom Wyant<br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253715.html Sat, 16 Feb 2019 16:31:56 +0000 Perl 5 Commit Summary by Perl 5 commit summary Perl 5 commit summary, activity since Wednesday<br/><br/>Current branch blead<br/>33 commits. 7 unique authors. 6 unique committers.<br/>146 files changed, 3089 insertions(+), 1889 deletions(-)<br/>Thanks, applied: James E Keenan (1)<br/>Snapshot: http://perl5.git.perl.org/perl.git/snapshot/d547f0460acfc340.tar.gz<br/><br/> Jakub Wilk is now a Perl author.<br/> James E Keenan 1 file changed, 1 insertion(+)<br/> http://perl5.git.perl.org/perl.git/commit/d547f0460acfc340<br/><br/> perlthrtut: Fix POD formatting<br/> Jakub Wilk 1 file changed, 3 insertions(+), 3 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/e161f2f4a061301b<br/><br/> Use STATIC_ASSERT_STMT for checking compile-time invariants<br/> Dagfinn Ilmari Manns&Atilde;&yen;ker 1 file changed, 2 insertions(+), 3 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/de8aedb225e5852b<br/><br/> Merge branch &#39;incore&#39; into blead<br/> Karl Williamson 2 parents<br/> http://perl5.git.perl.org/perl.git/commit/be76079c87db438e<br/><br/> Remove relics of regex swash use<br/> Karl Williamson 8 files changed, 63 insertions(+), 739 deletions<br/> http://perl5.git.perl.org/perl.git/commit/4c404f263914b5bf<br/><br/> Use mnemonics for array indices<br/> Karl Williamson 1 file changed, 26 insertions(+), 15 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/4ebed06a4c0245ff<br/><br/> regcomp.c: Arrays no longer need PL_sv_undef placeholders<br/> Karl Williamson 1 file changed, 22 insertions(+), 29 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/2410ba250b11206f<br/><br/> regcomp.c: Simplify args passing for ANYOF nodes<br/> Karl Williamson 2 files changed, 47 insertions(+), 94 deletions(<br/> http://perl5.git.perl.org/perl.git/commit/6ed02bb63446ea2c<br/><br/> Add .t for testing user-defined \p{} races<br/> Karl Williamson 2 files changed, 118 insertions(+)<br/> http://perl5.git.perl.org/perl.git/commit/36c2b2aa3853cfaf<br/><br/> t/re/regexp_unicode_prop.t: Make sure sub called only once<br/> Karl Williamson 1 file changed, 18 insertions(+), 5 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/a2fe6cf28f613880<br/><br/> t/re/regexp_unicode_prop.t: Add tests<br/> Karl Williamson 1 file changed, 76 insertions(+), 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/3b071feee62d0713<br/><br/> t/re/regexp_unicode_prop.t: Test that can have nested pkgs<br/> Karl Williamson 1 file changed, 2 insertions(+), 2 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/e4f9f79853e160e0<br/><br/> t/re/regexp_unicode_prop.t: Add some stress<br/> Karl Williamson 1 file changed, 8 insertions(+), 5 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/61ac831b8aceb592<br/><br/> t/op/taint.t: Add test<br/> Karl Williamson 1 file changed, 17 insertions(+), 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/c413aa1fa6bdc64c<br/><br/> regcomp.c: Add some potential code that&#39;s #ifdef&#39;d out<br/> Karl Williamson 1 file changed, 52 insertions(+)<br/> http://perl5.git.perl.org/perl.git/commit/de5659380e7c1c71<br/><br/> Move \p{user-defined} to core from utf8_heavy.pl<br/> Karl Williamson 8 files changed, 988 insertions(+), 245 deletion<br/> http://perl5.git.perl.org/perl.git/commit/73b95840bb1b55d7<br/><br/> Add global hash to handle \p{user-defined}<br/> Karl Williamson 5 files changed, 42 insertions(+), 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/dd52e3cc434f4c6a<br/><br/> Add mutex for dealing with qr/\p{user-defined}/<br/> Karl Williamson 8 files changed, 21 insertions(+), 3 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/8310e7fa48c5bce3<br/><br/> regcomp.c: Add/reword some comments/white-space<br/> Karl Williamson 1 file changed, 39 insertions(+), 41 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/3c5142a9e5aa4720<br/><br/> regcomp.c: Change variable name<br/> Karl Williamson 1 file changed, 13 insertions(+), 13 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/ba7ca5a8b3ea4d85<br/><br/> perldelta prep setup for v5.29.8<br/> Nicolas R 1 file changed, 46 insertions(+), 130 deletions(<br/> http://perl5.git.perl.org/perl.git/commit/9e8e4a84c278536d<br/><br/> perldelta module changes from ext,lib<br/> Nicolas R 1 file changed, 18 insertions(+), 50 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/d9ed9e94fd7c5f80<br/><br/> Update Modules section for perldelta for 5.29.8<br/> Nicolas R 1 file changed, 18 insertions(+)<br/> http://perl5.git.perl.org/perl.git/commit/7b97bf55c0bdc3d2<br/><br/> Update JSON-PP to CPAN version 4.00<br/> Nicolas R 40 files changed, 848 insertions(+), 396 deletio<br/> http://perl5.git.perl.org/perl.git/commit/5eabe05513a5c4b2<br/><br/> t/porting/manifest.t add line number<br/> Nicolas R 1 file changed, 3 insertions(+), 3 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/673bd1ed6f78d45d<br/><br/> Net::Ping 501_ping_icmpv6.t: disable sudo test<br/> Nicolas R 3 files changed, 3 insertions(+), 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/551524d7c29d0588<br/><br/> Update Net::Ping to upstream version 2.71<br/> Nicolas R 16 files changed, 547 insertions(+), 103 deletio<br/> http://perl5.git.perl.org/perl.git/commit/2e598186867b2c0c<br/><br/> Update Test-Simple to CPAN version 1.302162<br/> Chris &#39;BinGOs&#39; Williams 65 files changed, 66 insertions(+), 66 deletions<br/> http://perl5.git.perl.org/perl.git/commit/a6afdf72cdabc9d2<br/><br/> Update Module-Load to CPAN version 0.34<br/> Nicolas R 2 files changed, 22 insertions(+), 4 deletions(-<br/> http://perl5.git.perl.org/perl.git/commit/df56252693bd11e3<br/><br/> perlrecharclass: Note many fewer xdigits than digts<br/> Karl Williamson 1 file changed, 12 insertions(+), 2 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/7835a09a181366ad<br/><br/> perlrecharclass: Rmv obsolete RFC<br/> Karl Williamson 1 file changed, 6 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/4f5c9941bb6f93a9<br/><br/> perlrecharclass: Clarify<br/> Karl Williamson 1 file changed, 7 insertions(+), 7 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/8a0ab3a428cea294<br/><br/> (perl #133660) add test for goto &amp;sub in overload leaking<br/> Tony Cook 1 file changed, 21 insertions(+), 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/ac6d2595875ea281<br/><br/>Current branch smoke-me/khw-core<br/>5 commits. 1 unique author. 1 unique committer.<br/>135 files changed, 1862 insertions(+), 799 deletions(-)<br/><br/>Snapshot: http://perl5.git.perl.org/perl.git/snapshot/6466479c04f877be.tar.gz<br/><br/> trial<br/> Karl Williamson 26 files changed, 10731 insertions(+), 6928 dele<br/> http://perl5.git.perl.org/perl.git/commit/6466479c04f877be<br/><br/> Revert &quot;Filter::Util::Call no longer needs &#39;.&#39; in @INC&quot;<br/> Karl Williamson 1 file changed, 1 insertion(+)<br/> http://perl5.git.perl.org/perl.git/commit/151739505121bccf<br/><br/> Filter::Util::Call no longer needs &#39;.&#39; in @INC<br/> Karl Williamson 1 file changed, 1 deletion(-)<br/> http://perl5.git.perl.org/perl.git/commit/980a3e71117366bf<br/><br/> Revert &quot;experimental ucd&quot;<br/> Karl Williamson 1 file changed, 6 insertions(+), 20 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/2d19fad089a2f400<br/><br/> experimental ucd<br/> Karl Williamson 1 file changed, 20 insertions(+), 6 deletions(-)<br/> http://perl5.git.perl.org/perl.git/commit/2c6318956de35f7a<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253714.html Sat, 16 Feb 2019 03:08:26 +0000 Re: RFC: Adding \p{foo=/re/} by Karl Williamson Top posted, the link to the branch you can try out is <br/> <br/>https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-core <br/>On 2/15/19 10:25 AM, Karl Williamson wrote: <br/>&gt; On 2/11/19 6:13 PM, Deven T. Corzine wrote: <br/>&gt;&gt; On Sat, Feb 9, 2019 at 12:01 PM Karl Williamson <br/>&gt;&gt; &lt;public@khwilliamson.com &lt;mailto:public@khwilliamson.com&gt;&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; I&#39;m sorry for not being clear.&nbsp; Deven is correct that his <br/>&gt;&gt; hypothetical <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; implementation is what I have done. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; That&rsquo;s good to hear!&nbsp; I was hoping it would be implemented in such a <br/>&gt;&gt; fashion. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; This is a bolt-on feature to the Perl&#39;s regexes.&nbsp; It implements a <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; portion of the wildcard feature of what UTS 18 asks for, using their <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; syntax.&nbsp; It is an apparent goal, as long listed in perlunicode, to <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; do as <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; much of UTS 18 as we can. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; Using their syntax seems worthwhile even if we already deviate elsewhere. <br/>&gt;&gt; <br/>&gt;&gt; However, I must say that their last example in the table doesn&#39;t make <br/>&gt;&gt; sense to me <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Characters in the Letterlike symbol block with different toLowercase <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; values: <br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;[\p{toLowercase&ne;@cp@} &amp; \p{Block=Letterlike Symbols}] <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; This seems to imply some sort of boolean logic, which sounds good in <br/>&gt;&gt; principle, but this syntax seems bizarre to me.&nbsp; I would expect each <br/>&gt;&gt; \p{...} expression to be independent, but if they want two different <br/>&gt;&gt; property matches to apply as a set intersection, I think one of these <br/>&gt;&gt; examples this would be a more reasonable syntax: <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp; &nbsp; &nbsp;\p{toLowercase&ne;@cp@ &amp; Block=Letterlike Symbols} <br/>&gt;&gt; or <br/>&gt;&gt; &nbsp;&nbsp; &nbsp; &nbsp;\p{{toLowercase&ne;@cp@} &amp; {Block=Letterlike Symbols}} <br/>&gt; <br/>&gt; Well this implementation is just a start and doesn&#39;t include this <br/>&gt; fancier stuff, so we can defer deciding this until later. <br/>&gt;&gt; <br/>&gt;&gt; Also, on the topic of syntax, since these are meant to be used for <br/>&gt;&gt; sets of characters that can be used in a character class, I would <br/>&gt;&gt; suggest that these \p{...} expressions should also work *outside* <br/>&gt;&gt; square brackets as well, and imply [\p{...}] if the square brackets <br/>&gt;&gt; are omitted.&nbsp; (Perhaps you already do this too?) <br/>&gt; <br/>&gt; Yes, already. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; And the implementation isn&#39;t efficient. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; It is implemented by, during the compilation of a character class, <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; interrupting that compilation, assembling an inner pattern, then <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; compiling that and executing it to find all the code points it <br/>&gt;&gt; matches. <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; That list is then added to whatever else is in the character <br/>&gt;&gt; class, the <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; inner pattern&#39;s space is freed, and compilation of the outer pattern <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; resumed.&nbsp; There is no recursive execution.&nbsp; But there is recursion in <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; the sense, as I described, that a second pattern is compiled while in <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; the middle of compiling an outer pattern.&nbsp; I don&#39;t know if that is an <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; issue or not.&nbsp; The patterns do not share anything, no groups, etc. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; As long as it&#39;s all compile-time, it&#39;s probably plenty efficient <br/>&gt;&gt; enough already.&nbsp; Still, it might be worth keeping a cache of the <br/>&gt;&gt; \p{...} expressions used and the set of Unicode characters each <br/>&gt;&gt; generated, to avoid incurring the cost of generating the set if the <br/>&gt;&gt; same expressions are used over and over again.&nbsp; The cache could be <br/>&gt;&gt; discarded at the end of the compilation phase, either for the one <br/>&gt;&gt; containing regex, or (perhaps better) after compiling the entire <br/>&gt;&gt; program.&nbsp; Beyond that, I&#39;m not sure what else could be done to <br/>&gt;&gt; optimize it much more. <br/>&gt; <br/>&gt; I don&#39;t think the added complexity is worth it at this stage of <br/>&gt; development without real numbers to indicate that it is.&nbsp; And since <br/>&gt; eliminating a full pass of the compilation had no discernible effect, I <br/>&gt; doubt that a cache would either. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; I&#39;ve learned that a feature like this should be marked as <br/>&gt;&gt; experimental, <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; so that it can be refined or even removed, and marking it as such <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; lowers <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; expectations as to its well-thought-outness and bug-free-ness.&nbsp; It <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; allows us to try things out and get feedback without having to say we <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; think it is fully done.&nbsp; The prototype is so marked. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; Good idea, especially since a later official Unicode standard could <br/>&gt;&gt; change. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; I&#39;ve also learned that inefficiencies in compilation don&#39;t really <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; matter.&nbsp; I removed an entire pass of the regex compilation process, <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; with <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; extra mallocs being the price.&nbsp; There did not seem to be a noticeable <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; change in the speed of execution of our test suite!&nbsp; This inefficient <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; implementation (and I don&#39;t know another way to do it) won&#39;t be <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; noticeable in the end, because it&#39;s only done at compilation. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; I would agree with this.&nbsp; You&#39;re calling this implementation <br/>&gt;&gt; inefficient, but I&#39;m not sure that word applies if there isn&#39;t a <br/>&gt;&gt; substantially better way to do it.&nbsp; Creating a fixed character set at <br/>&gt;&gt; compile time is the thing that will make this efficient at runtime, <br/>&gt;&gt; and as long as the cost at compile time is small, it&#39;s not likely to <br/>&gt;&gt; even be noticed. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; I believe PCRE doesn&#39;t do this; I don&#39;t know about other engines. <br/>&gt;&gt; But <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; if no one does, I would think that us having a feature no one else <br/>&gt;&gt; does <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; is a selling point.&nbsp; If others do, we could perhaps learn from their <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; syntax.&nbsp; A quick google search didn&#39;t turn up anything obvious. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; I doubt anyone else does it yet.&nbsp; If Perl has it, perhaps PCRE would <br/>&gt;&gt; consider copying it later to try to maintain better compatibility with <br/>&gt;&gt; Perl, but they might not even bother. <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; If there are issues with various constructs, we can forbid those.&nbsp; My <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; implementation, for example, doesn&#39;t allow braces in the subpattern, <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; and <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; hence no construct that requires braces.&nbsp; I think that&#39;s a reasonable <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; initial restriction to make it easier to implement something, that <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; otherwise wouldn&#39;t get implemented. <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; It would be good to support balanced/escaped braces, but that can <br/>&gt;&gt; certainly be a second pass... <br/>&gt; <br/>&gt; What I&#39;m trying to do is give people the ability to do something, while <br/>&gt; punting niceties that aren&#39;t essential in favor of easier development. <br/>&gt; <br/>&gt;&gt; <br/>&gt;&gt; &nbsp;&nbsp;&nbsp; If the UTS 18 syntax is misleading, what isn&#39;t? <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; I&#39;m not even sure what you mean by this! <br/>&gt; <br/>&gt; I meant, if the reader doesn&#39;t like the syntax, make a different proposal. <br/>&gt; <br/>&gt; <br/>&gt; In any event, I&#39;ve pushed a new branch for people to play around with <br/>&gt; that eliminates the anchoring, and allows for more delimiter characters <br/>&gt; than the initial branch did. <br/>&gt;&gt; <br/>&gt;&gt; Deven <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253713.html Fri, 15 Feb 2019 17:52:32 +0000 Re: RFC: Adding \p{foo=/re/} by Karl Williamson On 2/11/19 6:13 PM, Deven T. Corzine wrote: <br/>&gt; On Sat, Feb 9, 2019 at 12:01 PM Karl Williamson &lt;public@khwilliamson.com <br/>&gt; &lt;mailto:public@khwilliamson.com&gt;&gt; wrote: <br/>&gt; <br/>&gt; I&#39;m sorry for not being clear.&nbsp; Deven is correct that his hypothetical <br/>&gt; implementation is what I have done. <br/>&gt; <br/>&gt; <br/>&gt; That&rsquo;s good to hear!&nbsp; I was hoping it would be implemented in such a <br/>&gt; fashion. <br/>&gt; <br/>&gt; This is a bolt-on feature to the Perl&#39;s regexes.&nbsp; It implements a <br/>&gt; portion of the wildcard feature of what UTS 18 asks for, using their <br/>&gt; syntax.&nbsp; It is an apparent goal, as long listed in perlunicode, to <br/>&gt; do as <br/>&gt; much of UTS 18 as we can. <br/>&gt; <br/>&gt; <br/>&gt; Using their syntax seems worthwhile even if we already deviate elsewhere. <br/>&gt; <br/>&gt; However, I must say that their last example in the table doesn&#39;t make <br/>&gt; sense to me <br/>&gt; <br/>&gt; Characters in the Letterlike symbol block with different toLowercase <br/>&gt; values: <br/>&gt; &nbsp; &nbsp; &nbsp;[\p{toLowercase&ne;@cp@} &amp; \p{Block=Letterlike Symbols}] <br/>&gt; <br/>&gt; <br/>&gt; This seems to imply some sort of boolean logic, which sounds good in <br/>&gt; principle, but this syntax seems bizarre to me.&nbsp; I would expect each <br/>&gt; \p{...} expression to be independent, but if they want two different <br/>&gt; property matches to apply as a set intersection, I think one of these <br/>&gt; examples this would be a more reasonable syntax: <br/>&gt; <br/>&gt; &nbsp; &nbsp; &nbsp;\p{toLowercase&ne;@cp@ &amp; Block=Letterlike Symbols} <br/>&gt; or <br/>&gt; &nbsp; &nbsp; &nbsp;\p{{toLowercase&ne;@cp@} &amp; {Block=Letterlike Symbols}} <br/> <br/>Well this implementation is just a start and doesn&#39;t include this <br/>fancier stuff, so we can defer deciding this until later. <br/>&gt; <br/>&gt; Also, on the topic of syntax, since these are meant to be used for sets <br/>&gt; of characters that can be used in a character class, I would suggest <br/>&gt; that these \p{...} expressions should also work *outside* square <br/>&gt; brackets as well, and imply [\p{...}] if the square brackets are <br/>&gt; omitted.&nbsp; (Perhaps you already do this too?) <br/> <br/>Yes, already. <br/>&gt; <br/>&gt; And the implementation isn&#39;t efficient. <br/>&gt; <br/>&gt; It is implemented by, during the compilation of a character class, <br/>&gt; interrupting that compilation, assembling an inner pattern, then <br/>&gt; compiling that and executing it to find all the code points it matches. <br/>&gt; That list is then added to whatever else is in the character class, the <br/>&gt; inner pattern&#39;s space is freed, and compilation of the outer pattern <br/>&gt; resumed.&nbsp; There is no recursive execution.&nbsp; But there is recursion in <br/>&gt; the sense, as I described, that a second pattern is compiled while in <br/>&gt; the middle of compiling an outer pattern.&nbsp; I don&#39;t know if that is an <br/>&gt; issue or not.&nbsp; The patterns do not share anything, no groups, etc. <br/>&gt; <br/>&gt; <br/>&gt; As long as it&#39;s all compile-time, it&#39;s probably plenty efficient enough <br/>&gt; already.&nbsp; Still, it might be worth keeping a cache of the \p{...} <br/>&gt; expressions used and the set of Unicode characters each generated, to <br/>&gt; avoid incurring the cost of generating the set if the same expressions <br/>&gt; are used over and over again.&nbsp; The cache could be discarded at the end <br/>&gt; of the compilation phase, either for the one containing regex, or <br/>&gt; (perhaps better) after compiling the entire program.&nbsp; Beyond that, I&#39;m <br/>&gt; not sure what else could be done to optimize it much more. <br/> <br/>I don&#39;t think the added complexity is worth it at this stage of <br/>development without real numbers to indicate that it is. And since <br/>eliminating a full pass of the compilation had no discernible effect, I <br/>doubt that a cache would either. <br/>&gt; <br/>&gt; I&#39;ve learned that a feature like this should be marked as experimental, <br/>&gt; so that it can be refined or even removed, and marking it as such <br/>&gt; lowers <br/>&gt; expectations as to its well-thought-outness and bug-free-ness.&nbsp; It <br/>&gt; allows us to try things out and get feedback without having to say we <br/>&gt; think it is fully done.&nbsp; The prototype is so marked. <br/>&gt; <br/>&gt; <br/>&gt; Good idea, especially since a later official Unicode standard could change. <br/>&gt; <br/>&gt; I&#39;ve also learned that inefficiencies in compilation don&#39;t really <br/>&gt; matter.&nbsp; I removed an entire pass of the regex compilation process, <br/>&gt; with <br/>&gt; extra mallocs being the price.&nbsp; There did not seem to be a noticeable <br/>&gt; change in the speed of execution of our test suite!&nbsp; This inefficient <br/>&gt; implementation (and I don&#39;t know another way to do it) won&#39;t be <br/>&gt; noticeable in the end, because it&#39;s only done at compilation. <br/>&gt; <br/>&gt; <br/>&gt; I would agree with this.&nbsp; You&#39;re calling this implementation <br/>&gt; inefficient, but I&#39;m not sure that word applies if there isn&#39;t a <br/>&gt; substantially better way to do it.&nbsp; Creating a fixed character set at <br/>&gt; compile time is the thing that will make this efficient at runtime, and <br/>&gt; as long as the cost at compile time is small, it&#39;s not likely to even be <br/>&gt; noticed. <br/>&gt; <br/>&gt; I believe PCRE doesn&#39;t do this; I don&#39;t know about other engines.&nbsp; But <br/>&gt; if no one does, I would think that us having a feature no one else does <br/>&gt; is a selling point.&nbsp; If others do, we could perhaps learn from their <br/>&gt; syntax.&nbsp; A quick google search didn&#39;t turn up anything obvious. <br/>&gt; <br/>&gt; <br/>&gt; I doubt anyone else does it yet.&nbsp; If Perl has it, perhaps PCRE would <br/>&gt; consider copying it later to try to maintain better compatibility with <br/>&gt; Perl, but they might not even bother. <br/>&gt; <br/>&gt; If there are issues with various constructs, we can forbid those.&nbsp; My <br/>&gt; implementation, for example, doesn&#39;t allow braces in the subpattern, <br/>&gt; and <br/>&gt; hence no construct that requires braces.&nbsp; I think that&#39;s a reasonable <br/>&gt; initial restriction to make it easier to implement something, that <br/>&gt; otherwise wouldn&#39;t get implemented. <br/>&gt; <br/>&gt; <br/>&gt; It would be good to support balanced/escaped braces, but that can <br/>&gt; certainly be a second pass... <br/> <br/>What I&#39;m trying to do is give people the ability to do something, while <br/>punting niceties that aren&#39;t essential in favor of easier development. <br/> <br/>&gt; <br/>&gt; If the UTS 18 syntax is misleading, what isn&#39;t? <br/>&gt; <br/>&gt; <br/>&gt; I&#39;m not even sure what you mean by this! <br/> <br/>I meant, if the reader doesn&#39;t like the syntax, make a different proposal. <br/> <br/> <br/>In any event, I&#39;ve pushed a new branch for people to play around with <br/>that eliminates the anchoring, and allows for more delimiter characters <br/>than the initial branch did. <br/>&gt; <br/>&gt; Deven <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253712.html Fri, 15 Feb 2019 17:25:56 +0000 [perl #133848] [PATCH] perlthrtut: Fix POD formatting by James E Keenan via RT On Thu, 14 Feb 2019 20:45:27 GMT, jwilk@jwilk.net wrote:<br/>&gt; <br/><br/>Thanks. Pushed to blead in commit e161f2f4a061301b0908fa5755b3584408ca46d7.<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=133848<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253711.html Fri, 15 Feb 2019 12:59:41 +0000 Re: TONYC Grant Report January 2019 by Marcus Holland-Moritz On 2019-02-15, at 10:14:53 +1100, Tony Cook wrote: <br/> <br/>&gt; Approximately 54 tickets were reviewed, and 11 patches were <br/>&gt; applied <br/> <br/>Thanks Tony, +1! <br/> <br/> <br/> <br/>&gt; [Hours] [Activity] <br/>&gt; 8.88 #108276 review <br/>&gt; #108276 check over committed changes, look to re-work, ask <br/>&gt; list about PERL_OP_PARENT <br/>&gt; #108276 cleanup PERL_OP_PARENT detritus <br/>&gt; #108276 review old patches, re-work, testing <br/>&gt; #108276 more testing, work on optimize_op() <br/>&gt; #108276 research, cleanup, more testing. Comment with <br/>&gt; patch <br/>&gt; 0.58 #121033 research, comment <br/>&gt; 1.98 #123724 rebase, retesting, bump versions, apply to blead, <br/>&gt; make public <br/>&gt; 0.05 #126191 check for activity and close <br/>&gt; 2.69 #127521 review code, POSIX, work on implementation <br/>&gt; #127521 local commit with notes <br/>&gt; 1.72 #130367 rebase, write new tests, testing, apply to blead <br/>&gt; #130367 perldelta <br/>&gt; 1.90 #130585 debugging <br/>&gt; #130585 debugging <br/>&gt; 0.32 #131506 research and comment <br/>&gt; #131506 close <br/>&gt; 0.07 #131931 link to stack-not-refcounted meta ticket <br/>&gt; 0.08 #131955 check for activity and close <br/>&gt; 0.52 #132158 rebase, retest and apply to blead <br/>&gt; 1.35 #132338 research, comment <br/>&gt; 0.12 #132583 same and add the form sub-parse fix to backports <br/>&gt; (the other is in 5.28 already) <br/>&gt; 3.76 #132777 prep, review code, research, work on some docs <br/>&gt; #132777 testing, more docs, comment with patch <br/>&gt; 0.27 #133030 re-check, comment <br/>&gt; 0.27 #133153 comment <br/>&gt; 0.62 #133504 research and comment <br/>&gt; 0.55 #133522 review patch, testing, apply to blead <br/>&gt; 1.88 #133524 work up a fix and apply to blead <br/>&gt; 3.88 #133575 prep and start gcc 8.2.0 build <br/>&gt; #133575 work up a patch, testing, comment with patch <br/>&gt; #133575 consider comment changes, research, testing, apply <br/>&gt; to blead <br/>&gt; 0.60 #133590 try to work with metaconfig, report upstream to <br/>&gt; the metaconfig wizards <br/>&gt; 0.77 #133721 review, write test, testing, apply test and fix to <br/>&gt; blead <br/>&gt; 0.13 #133740 review new patch and comment <br/>&gt; 0.13 #133744 review and comment <br/>&gt; 0.10 #133746 review and close <br/>&gt; 0.10 #133750 review and reject <br/>&gt; 1.00 #133751 comment with patch <br/>&gt; #133751 retest, apply to blead <br/>&gt; 0.55 #133752 follow up <br/>&gt; #133752 got a response privately due to rt.perl.org <br/>&gt; issues, forwarded request to perlbug-admin and closed <br/>&gt; tickets <br/>&gt; 0.25 #133753 (sec) fix subject, comment <br/>&gt; #133753 (sec) testing, comment <br/>&gt; 1.82 #133754 test setup, testing, research <br/>&gt; 2.08 #133755 research, produce a patch and comment <br/>&gt; #133755 fix a typo, test, apply to blead <br/>&gt; #133755 comment and close <br/>&gt; 0.25 #133756 review and comment briefly <br/>&gt; 0.61 #133760 research and comment <br/>&gt; #133760 research (read the Configure source) and comment <br/>&gt; 0.72 #133765 review, start prep to test, review code, comment <br/>&gt; #133765 research, add commit to votes file <br/>&gt; 0.53 #133771 review patch and comment <br/>&gt; #133771 review new patch and comment <br/>&gt; 0.97 #133776 review and comment <br/>&gt; #133776 review and comment <br/>&gt; 3.32 #133782 diagnose, work on a fix, testing <br/>&gt; #133782 retest patch against blead, apply to blead <br/>&gt; #133782 re-test, fix ticket number in patch, apply to <br/>&gt; blead <br/>&gt; 0.38 #133787 research (more Configure) and comment <br/>&gt; 0.33 #133788 research history of APIs, remove M flag and apply <br/>&gt; to blead <br/>&gt; 1.07 #133789 debugging, comment <br/>&gt; 0.25 #133806 bump $IO::VERSION, testing <br/>&gt; 2.35 add t/ file leak checks and TMPDIR leak checks <br/>&gt; 0.48 look for possibly fixed sub-parse tokenizer bugs, find a <br/>&gt; couple and comment, bookmark for later closing <br/>&gt; 0.72 look for some more possibly fixed tokenizer bugs <br/>&gt; 2.82 look into detecting shmem leaks reported by Tux, <br/>&gt; https://github.com/Test-More/test-more/issues/823 <br/>&gt; 0.17 review maint votes, remove one already picked <br/>&gt; 1.07 utf8-readline: build fixes, debugging <br/>&gt; 1.50 utf8-readline: clean up, consider re-working options <br/>&gt; 0.62 utf8-readline: debug failing tests <br/>&gt; 2.33 utf8-readline: debugging <br/>&gt; 2.52 utf8-readline: debugging, fixes for buffer parsing tests <br/>&gt; 0.32 utf8-readline: more debugging failing tests <br/>&gt; 0.10 utf8-readline: rebase, review <br/>&gt; 2.80 utf8-readline: track down a fix warning handling <br/>&gt; ====== <br/>&gt; 65.25 hours total <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253710.html Fri, 15 Feb 2019 08:59:16 +0000 TONYC Grant Report January 2019 by Tony Cook Approximately 54 tickets were reviewed, and 11 patches were<br/>applied<br/><br/>[Hours] [Activity]<br/> 8.88 #108276 review<br/> #108276 check over committed changes, look to re-work, ask<br/> list about PERL_OP_PARENT<br/> #108276 cleanup PERL_OP_PARENT detritus<br/> #108276 review old patches, re-work, testing<br/> #108276 more testing, work on optimize_op()<br/> #108276 research, cleanup, more testing. Comment with<br/> patch<br/> 0.58 #121033 research, comment<br/> 1.98 #123724 rebase, retesting, bump versions, apply to blead,<br/> make public<br/> 0.05 #126191 check for activity and close<br/> 2.69 #127521 review code, POSIX, work on implementation<br/> #127521 local commit with notes<br/> 1.72 #130367 rebase, write new tests, testing, apply to blead<br/> #130367 perldelta<br/> 1.90 #130585 debugging<br/> #130585 debugging<br/> 0.32 #131506 research and comment<br/> #131506 close<br/> 0.07 #131931 link to stack-not-refcounted meta ticket<br/> 0.08 #131955 check for activity and close<br/> 0.52 #132158 rebase, retest and apply to blead<br/> 1.35 #132338 research, comment<br/> 0.12 #132583 same and add the form sub-parse fix to backports<br/> (the other is in 5.28 already)<br/> 3.76 #132777 prep, review code, research, work on some docs<br/> #132777 testing, more docs, comment with patch<br/> 0.27 #133030 re-check, comment<br/> 0.27 #133153 comment<br/> 0.62 #133504 research and comment<br/> 0.55 #133522 review patch, testing, apply to blead<br/> 1.88 #133524 work up a fix and apply to blead<br/> 3.88 #133575 prep and start gcc 8.2.0 build<br/> #133575 work up a patch, testing, comment with patch<br/> #133575 consider comment changes, research, testing, apply<br/> to blead<br/> 0.60 #133590 try to work with metaconfig, report upstream to<br/> the metaconfig wizards<br/> 0.77 #133721 review, write test, testing, apply test and fix to<br/> blead<br/> 0.13 #133740 review new patch and comment<br/> 0.13 #133744 review and comment<br/> 0.10 #133746 review and close<br/> 0.10 #133750 review and reject<br/> 1.00 #133751 comment with patch<br/> #133751 retest, apply to blead<br/> 0.55 #133752 follow up<br/> #133752 got a response privately due to rt.perl.org<br/> issues, forwarded request to perlbug-admin and closed<br/> tickets<br/> 0.25 #133753 (sec) fix subject, comment<br/> #133753 (sec) testing, comment<br/> 1.82 #133754 test setup, testing, research<br/> 2.08 #133755 research, produce a patch and comment<br/> #133755 fix a typo, test, apply to blead<br/> #133755 comment and close<br/> 0.25 #133756 review and comment briefly<br/> 0.61 #133760 research and comment<br/> #133760 research (read the Configure source) and comment<br/> 0.72 #133765 review, start prep to test, review code, comment<br/> #133765 research, add commit to votes file<br/> 0.53 #133771 review patch and comment<br/> #133771 review new patch and comment<br/> 0.97 #133776 review and comment<br/> #133776 review and comment<br/> 3.32 #133782 diagnose, work on a fix, testing<br/> #133782 retest patch against blead, apply to blead<br/> #133782 re-test, fix ticket number in patch, apply to<br/> blead<br/> 0.38 #133787 research (more Configure) and comment<br/> 0.33 #133788 research history of APIs, remove M flag and apply<br/> to blead<br/> 1.07 #133789 debugging, comment<br/> 0.25 #133806 bump $IO::VERSION, testing<br/> 2.35 add t/ file leak checks and TMPDIR leak checks<br/> 0.48 look for possibly fixed sub-parse tokenizer bugs, find a<br/> couple and comment, bookmark for later closing<br/> 0.72 look for some more possibly fixed tokenizer bugs<br/> 2.82 look into detecting shmem leaks reported by Tux,<br/> https://github.com/Test-More/test-more/issues/823<br/> 0.17 review maint votes, remove one already picked<br/> 1.07 utf8-readline: build fixes, debugging<br/> 1.50 utf8-readline: clean up, consider re-working options<br/> 0.62 utf8-readline: debug failing tests<br/> 2.33 utf8-readline: debugging<br/> 2.52 utf8-readline: debugging, fixes for buffer parsing tests<br/> 0.32 utf8-readline: more debugging failing tests<br/> 0.10 utf8-readline: rebase, review<br/> 2.80 utf8-readline: track down a fix warning handling<br/>======<br/> 65.25 hours total<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253709.html Thu, 14 Feb 2019 23:15:13 +0000 TONYC TPF Grant 11 report 26 by Tony Cook [Hours] [Activity]<br/>2019/01/28 Monday<br/> 2.82 look into detecting shmem leaks reported by Tux,<br/> https://github.com/Test-More/test-more/issues/823<br/> 2.35 add t/ file leak checks and TMPDIR leak checks<br/>=====<br/> 5.17<br/><br/>2019/01/29 Tuesday<br/> 1.65 #108276 review old patches, re-work, testing<br/> 2.97 #108276 more testing, work on optimize_op()<br/> 0.25 #133806 bump $IO::VERSION, testing<br/>=====<br/> 4.87<br/><br/>2019/01/30 Wednesday<br/> 0.98 #133782 re-test, fix ticket number in patch, apply to<br/> blead<br/> 0.13 #133744 review and comment<br/> 1.28 #108276 research, cleanup, more testing. Comment with<br/> patch<br/>=====<br/> 2.39<br/><br/>2019/01/31 Thursday<br/> 1.38 #132777 prep, review code, research, work on some docs<br/> 2.38 #132777 testing, more docs, comment with patch<br/>=====<br/> 3.76<br/><br/>Which I calculate is 16.19 hours.<br/><br/>Approximately 5 tickets were reviewed or worked on, and 1 patches<br/>were applied.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253708.html Thu, 14 Feb 2019 23:13:17 +0000 TONYC TPF Grant 11 report 25 by Tony Cook [Hours] [Activity]<br/>2019/01/21 Monday<br/> 1.77 #133782 diagnose, work on a fix, testing<br/> 0.17 #133776 review and comment<br/> 0.48 look for possibly fixed sub-parse tokenizer bugs, find a<br/> couple and comment, bookmark for later closing<br/> 0.57 #133782 retest patch against blead, apply to blead<br/> 0.72 look for some more possibly fixed tokenizer bugs<br/> 0.60 #130585 debugging<br/>=====<br/> 4.31<br/><br/>2019/01/22 Tuesday<br/> 0.80 #133776 review and comment<br/> 0.15 #133771 review new patch and comment<br/> 1.62 #130367 rebase, write new tests, testing, apply to blead<br/> 0.10 #130367 perldelta<br/> 0.62 #133751 retest, apply to blead<br/> 1.30 #130585 debugging<br/>=====<br/> 4.59<br/><br/>2019/01/23 Wednesday<br/> 0.18 #133760 research (read the Configure source) and comment<br/> 0.38 #133787 research (more Configure) and comment<br/> 0.33 #133788 research history of APIs, remove M flag and apply<br/> to blead<br/> 1.07 #133789 debugging, comment<br/> 0.27 #133153 comment<br/> 0.10 #133752 follow up<br/> 0.10 #133750 review and reject<br/> 0.10 #133746 review and close<br/>=====<br/> 2.53<br/><br/>2019/01/24 Thursday<br/> 0.45 #133752 got a response privately due to rt.perl.org<br/> issues, forwarded request to perlbug-admin and closed<br/> tickets<br/> 0.05 #126191 check for activity and close<br/> 0.08 #131955 check for activity and close<br/> 0.12 #132583 same and add the form sub-parse fix to backports<br/> (the other is in 5.28 already)<br/> 0.13 #133755 comment and close<br/> 0.45 #108276 review<br/> 0.75 #108276 check over committed changes, look to re-work, ask<br/> list about PERL_OP_PARENT<br/>=====<br/> 2.03<br/><br/>2019/01/25 Friday<br/> 1.78 #108276 cleanup PERL_OP_PARENT detritus<br/>=====<br/> 1.78<br/><br/>Which I calculate is 15.24 hours.<br/><br/>Approximately 19 tickets were reviewed or worked on, and 4 patches<br/>were applied.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253707.html Thu, 14 Feb 2019 23:10:26 +0000 Re: [perl #132964] Missing newSVsv_nomg macro variant by pali On Tuesday 12 February 2019 20:08:47 Tony Cook via RT wrote:<br/>&gt; On Thu, 07 Feb 2019 05:22:52 -0800, pali@cpan.org wrote:<br/>&gt; &gt; In attachment is implementation of newSVsv_nomg() variant macro which<br/>&gt; &gt; does not process get magic on input scalar.<br/>&gt; <br/>&gt; Why not make SV_NOSTEAL significant for newSVsv_flags() ?<br/>&gt; <br/>&gt; Otherwise it will be messy adding it in the future.<br/><br/>Ok. In attachment is updated V2 patch which supports all flags like<br/>sv_setsv_flags() function. So not only SV_NOSTEAL, but also<br/>SV_COW_SHARED_HASH_KEYS.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253706.html Thu, 14 Feb 2019 11:46:11 +0000 [perl #133846] [PATCH] Devel::PPPort: Fix D_PPP_FIX_UTF8_ERRSV macro by perlbug-followup # New Ticket Created by <br/># Please include the string: [perl #133846]<br/># in the subject line of all future correspondence about this issue. <br/># &lt;URL: https://rt.perl.org/Ticket/Display.html?id=133846 &gt;<br/><br/><br/>It should use errsv value from passed argument.<br/><br/>perl keyword<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253705.html Thu, 14 Feb 2019 11:39:20 +0000 Re: [perl #131683] Encode::ONLY_PRAGMA_WARNINGS in$PerlIO::encoding::fallback by pali On Wednesday 13 February 2019 09:36:31 pali@cpan.org wrote:<br/>&gt; On Tuesday 12 February 2019 20:54:11 Tony Cook via RT wrote:<br/>&gt; &gt; On Tue, 12 Feb 2019 07:46:22 -0800, pali@cpan.org wrote:<br/>&gt; &gt; &gt; On Thursday 07 February 2019 16:05:40 pali@cpan.org wrote:<br/>&gt; &gt; &gt; &gt; On Tuesday 22 January 2019 09:38:38 pali@cpan.org wrote:<br/>&gt; &gt; &gt; &gt; &gt; On Monday 21 January 2019 15:03:02 Leon Timmermans via RT wrote:<br/>&gt; &gt; &gt; &gt; &gt; &gt; On Mon, Jan 21, 2019 at 6:51 PM &lt;pali@cpan.org&gt; wrote:<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ...and apply remaining<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; PerlIO::encoding patch?<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Can you specify which of the patches attached to this RT is<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; the one still under consideration?<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; 0002-PerlIO-encoding-Use-Encode-ONLY_PRAGMA_WARNINGS-in-f.patch<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; All other patches are part of Encode, and therefore applied.<br/>&gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; Can you add a perldelta entry?<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; I do not know where is correct place to put entries, nor what is<br/>&gt; &gt; &gt; &gt; &gt; correct<br/>&gt; &gt; &gt; &gt; &gt; formatting... But entry could contain something like this:<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; ===<br/>&gt; &gt; &gt; &gt; &gt; Modules PerlIO::encoding and Encode were fixed to respect state of<br/>&gt; &gt; &gt; &gt; &gt; utf8<br/>&gt; &gt; &gt; &gt; &gt; pragma warnings when processing filehandle with :encoding layer.<br/>&gt; &gt; &gt; &gt; &gt; ===<br/>&gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; Leon, it is enough?<br/>&gt; &gt; &gt; <br/>&gt; &gt; &gt; PING<br/>&gt; &gt; <br/>&gt; &gt; Do you mean the patch:<br/>&gt; &gt; <br/>&gt; &gt; - Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::STOP_AT_PARTIAL();<br/>&gt; &gt; + Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::ONLY_PRAGMA_WARNINGS()|Encode::STOP_AT_PARTIAL();<br/>&gt; &gt; <br/>&gt; <br/>&gt; Yes.<br/>&gt; <br/>&gt; &gt; which fails a test:<br/>&gt; &gt; <br/>&gt; &gt; ../ext/PerlIO-encoding/t/fallback.t (Wstat: 256 Tests: 10 Failed: 1)<br/>&gt; &gt; Failed test: 2<br/>&gt; &gt; Non-zero exit status: 1<br/>&gt; <br/>&gt; It started failing? Ah :-( IIRC it worked when I created it year ago.<br/>&gt; <br/>&gt; I will look at it...<br/><br/>Hi! Following patch should fix this problem. There is missing<br/>&quot;use warnings&quot; and also &quot;my $line&quot; is declared more times.<br/><br/>diff --git a/ext/PerlIO-encoding/t/fallback.t b/ext/PerlIO-encoding/t/fallback.t<br/>index 3abdfd3f37..84ba097e71 100644<br/>--- a/ext/PerlIO-encoding/t/fallback.t<br/>+++ b/ext/PerlIO-encoding/t/fallback.t<br/>@@ -16,11 +16,13 @@ BEGIN {<br/> import Encode qw(:fallback_all);<br/> }<br/> <br/>+use warnings;<br/> use Test::More tests =&gt; 10;<br/> <br/> # $PerlIO::encoding = 0; # WARN_ON_ERR|PERLQQ;<br/> <br/> my $file = &quot;fallback$$.txt&quot;;<br/>+my $line;<br/> <br/> {<br/> my $message = &#39;&#39;;<br/>@@ -34,7 +36,7 @@ my $file = &quot;fallback$$.txt&quot;;<br/> }<br/> <br/> open($fh,&#39;&lt;&#39;,$file) || die &quot;File cannot be re-opened&quot;;<br/>-my $line = &lt;$fh&gt;;<br/>+$line = &lt;$fh&gt;;<br/> is($line,&quot;\\x{20ac}0.02\n&quot;,&quot;perlqq escapes&quot;);<br/> close($fh);<br/> <br/>@@ -46,7 +48,7 @@ print $fh $str,&quot;0.02\n&quot;;<br/> close($fh);<br/> <br/> open($fh,&#39;&lt;&#39;,$file) || die &quot;File cannot be re-opened&quot;;<br/>-my $line = &lt;$fh&gt;;<br/>+$line = &lt;$fh&gt;;<br/> is($line,&quot;&amp;#8364;0.02\n&quot;,&quot;HTML escapes&quot;);<br/> close($fh);<br/> <br/>@@ -59,7 +61,7 @@ close($fh);<br/> }<br/> <br/> ok(open($fh,&quot;&lt;encoding(US-ASCII)&quot;,$file),&quot;Opened as ASCII&quot;);<br/>-my $line = &lt;$fh&gt;;<br/>+$line = &lt;$fh&gt;;<br/> printf &quot;# %x\n&quot;,ord($line);<br/> is($line,&quot;\\xA30.02\n&quot;,&quot;Escaped non-mapped char&quot;);<br/> close($fh);<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253704.html Thu, 14 Feb 2019 09:08:25 +0000 [perl #133638] The rendering of perlapi on metacpan by Tony Cook via RT On Mon, 19 Nov 2018 04:44:50 -0800, davem wrote:<br/>&gt; On Sat, Nov 10, 2018 at 11:30:49AM +0200, Sawyer X wrote:<br/>&gt; &gt; I think we should resolve this on the Perl side. One suggestion is to<br/>&gt; &gt; render the perlapi POD files during the release cycle and not<br/>&gt; &gt; compilation, which I think makes sense. We could ship static POD<br/>&gt; &gt; files<br/>&gt; &gt; for the API.<br/>&gt; <br/>&gt; I have just pushed v5.29.4-88-g6a4c4cd41c, which escapes any pod in<br/>&gt; autodoc.pl.<br/>&gt; <br/>&gt; I&#39;m not keen on messing with when perlapi.pod is generated, nor<br/>&gt; how/whether perldelta.pod is a link.<br/><br/>I agree.<br/><br/>Ideally this would go on perldoc.perl.org, but that&#39;s very out of date (none of 5.28.[01], 5.26.[23], 5.24.[1-3] are available.<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133638<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253703.html Thu, 14 Feb 2019 00:33:13 +0000 [perl #133695] Range Operator inconsistency? by Tony Cook via RT On Fri, 30 Nov 2018 06:09:07 -0800, haukex@zero-g.net wrote:<br/>&gt; Hi,<br/>&gt; <br/>&gt; Thanks for looking into this!<br/>&gt; <br/>&gt; The code comment in the code you showed [1] mentions #18165 [2] which<br/>&gt; references #18114 [3] where a reply by Slaven Rezic makes sense to me:<br/>&gt; &#39;There is a special handling for numeric strings beginning with a &quot;0&quot;.<br/>&gt; This is to allow things like &quot;01&quot;..&quot;31&quot; to preserve the leading zero<br/>&gt; for one-digit numbers.&#39; The basic behavior appears to go all the way<br/>&gt; back to 5.000 [4].<br/>&gt; <br/>&gt; [1]<br/>&gt; https://perl5.git.perl.org/perl.git/blob/23665de87341f4f3452009759d4fc95ce30b8ced:/pp_ctl.c#l1179<br/>&gt; [2] https://rt.perl.org/Public/Bug/Display.html?id=18165<br/>&gt; [3] https://rt.perl.org/Public/Bug/Display.html?id=18114<br/>&gt; [4] https://perl5.git.perl.org/perl.git/blob/refs/tags/perl-<br/>&gt; 5.000:/pp_ctl.c#l694<br/>&gt; <br/>&gt; So my interpretation of the rules is this: If the left and right<br/>&gt; operands are strings, then check if they looks_like_number. If they<br/>&gt; do, treat them as integers. However, make an exception when the left-<br/>&gt; hand side begins with &quot;0&quot;, for the reason stated above.<br/>&gt; <br/>&gt; The key word here is *begins* with zero; the condition<br/>&gt; *SvPVX_const(left)!=&#39;0&#39; causes this inconsistency:<br/>&gt; <br/>&gt; -3..-1 and &quot;-3&quot;..&quot;-1&quot; are (-3,-2,-1)<br/>&gt; -2..-1 and &quot;-2&quot;..&quot;-1&quot; are (-2,-1)<br/>&gt; -1..-1 and &quot;-1&quot;..&quot;-1&quot; are (-1)<br/>&gt; 1..-1 and &quot;1&quot;..&quot;-1&quot; are ()<br/>&gt; however:<br/>&gt; 0..-1 is () but &quot;0&quot;..&quot;-1&quot; is (0..99)<br/>&gt; <br/>&gt; That latter behavior may be in line with &quot;01&quot;..&quot;-1&quot;, which is<br/>&gt; (&quot;01&quot;,&quot;02&quot;,&quot;03&quot;,...), but IMO it&#39;s still surprising, and in any case<br/>&gt; the fact that strings that look like numbers are treated as such<br/>&gt; appears to be undocumented.<br/>&gt; <br/>&gt; I have two alternative proposals: (A) leave the behavior as-is, but<br/>&gt; document it, or (B) change the behavior so that the above condition is<br/>&gt; &#39;if the LHS is a string that begins with 0, except for the string &quot;0&quot;<br/>&gt; itself&#39; (and document it) - this would cause the &quot;01&quot;..&quot;31&quot; case to<br/>&gt; still work, but also cause &quot;0&quot;..&quot;-1&quot; to act like 0..-1.<br/>&gt; <br/>&gt; Patches for both A (just document) and B (change behavior) are<br/>&gt; attached, with tests included (a full build passes all tests on my<br/>&gt; end). My internals knowledge is quite limited so I hope my use of<br/>&gt; SvCUR in the second patch is correct.<br/>&gt; <br/>&gt; My personal preference is option B, since it gets rid of the above<br/>&gt; inconsistency, but I understand that if there are worries about<br/>&gt; backwards compatibility; option A may be better in that respect. The<br/>&gt; way I&#39;ve worded the documentation pretty much nails down the behavior<br/>&gt; and wouldn&#39;t allow for future changes, a third option might be to word<br/>&gt; the documentation more loosely and leave the door open for future<br/>&gt; changes.<br/><br/>I think I prefer B too. It would be nice to find out what anyone else thinks.<br/><br/>Unfortunately I don&#39;t think I&#39;d want to put a change in behaviour into core at this point in the release cycle.<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133695<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253702.html Wed, 13 Feb 2019 23:59:05 +0000 [perl #133670] "perlos400" updates by Tony Cook via RT On Mon, 19 Nov 2018 15:43:35 -0800, tonyc wrote:<br/>&gt; On Mon, 19 Nov 2018 11:46:01 -0800, jgorzins@us.ibm.com wrote:<br/>&gt; &gt; Hello.<br/>&gt; &gt;<br/>&gt; &gt; I ran across this page today: https://perldoc.perl.org/perlos400.html<br/>&gt; &gt;<br/>&gt; &gt; I work for IBM, and am in charge of open source offerings on our IBM<br/>&gt; &gt; i<br/>&gt; &gt; operating system. IBM i is the successor to &quot;OS/400&quot;. IBM builds and<br/>&gt; &gt; distributes perl for IBM i PASE users (the os400 page references<br/>&gt; &gt; &quot;OS/400<br/>&gt; &gt; PASE&quot;). It can be installed via a simple &quot;yum install perl&quot; so much<br/>&gt; &gt; of the<br/>&gt; &gt; PASE content can be replaced with a few links to IBM community<br/>&gt; &gt; documenation. The statements about &quot;Perl on ILE&quot; are still true.<br/>&gt; &gt;<br/>&gt; &gt; In any event, I&#39;d like to take a stab at updating this page. What is<br/>&gt; &gt; the<br/>&gt; &gt; proper process for doing so? Is it just email to this address?<br/>&gt; &gt;<br/>&gt; &gt; Thanks in advance for your collaboration, and of course thanks for<br/>&gt; &gt; Perl!<br/>&gt; <br/>&gt; The perl source, including the source for perlos400.pod (copied from<br/>&gt; README.os400), is maintained in our git repository.<br/>&gt; <br/>&gt; See the top of perldoc perlhack (or<br/>&gt; http://perldoc.perl.org/perlhack.html) for documentation on how to get<br/>&gt; the source, modify and test it, and submit patches.<br/><br/>Hi,<br/><br/>Your original question has been answered, so I&#39;ll be closing this ticket.<br/><br/>Once you have patches for README.os400 please either post them to perl5-porters or perlbug and we&#39;ll look at applying them to perl.<br/><br/>Thanks,<br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133670<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253701.html Wed, 13 Feb 2019 23:42:37 +0000 [perl #133771] ext/File-Find/t/*.t: Continued intermittent failuresduring parallel testing by Tony Cook via RT On Mon, 28 Jan 2019 14:52:18 -0800, jkeenan wrote:<br/>&gt; On Wed, 23 Jan 2019 20:24:27 GMT, jkeenan wrote:<br/>&gt; &gt; On Mon, 21 Jan 2019 22:52:57 GMT, tonyc wrote:<br/>&gt; &gt; &gt; On Mon, 21 Jan 2019 12:09:17 -0800, jkeenan wrote:<br/>&gt; &gt; &gt; &gt; On Fri, 18 Jan 2019 02:55:24 GMT, tonyc wrote:<br/>&gt; &gt; &gt; &gt; &gt; On Thu, Jan 17, 2019 at 05:02:29AM -0800, James E Keenan via RT<br/>&gt; &gt; &gt; &gt; &gt; wrote:<br/>&gt; &gt; &gt; &gt; &gt; &gt; Let me pose this question: Would we be better off using<br/>&gt; &gt; &gt; &gt; &gt; &gt; File::Spec-<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; tmpdir() to create the top-level of the testing<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; directories,<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; then<br/>&gt; &gt; &gt; &gt; &gt; &gt; creating for_find/ underneath that directory (in most cases,<br/>&gt; &gt; &gt; &gt; &gt; &gt; /tmp)?<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; I don&#39;t think it will make a difference over just searching<br/>&gt; &gt; &gt; &gt; &gt; within<br/>&gt; &gt; &gt; &gt; &gt; t/for_find.<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; Tony<br/>&gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; Please review patch 0001-find.t-Use-temporary-testing-directory-<br/>&gt; &gt; &gt; &gt; for-<br/>&gt; &gt; &gt; &gt; all-block.201901211500.patch, attached.<br/>&gt; &gt; &gt;<br/>&gt; &gt; &gt; That looks better.<br/>&gt; &gt; &gt;<br/>&gt; &gt; &gt; Tony<br/>&gt; &gt;<br/>&gt; &gt; Merged to blead in commit 0abd1628824e7e5b7d6df370fcf5c143bf2dab8d.<br/>&gt; &gt; Will monitor ticket for several days before closing.<br/>&gt; &gt;<br/>&gt; &gt; Thank you very much.<br/>&gt; <br/>&gt; Unfortunately, we don&#39;t have the problem licked. See this smoke-test<br/>&gt; report:<br/>&gt; <br/>&gt; http://perl5.test-smoke.org/report/79324<br/>&gt; <br/>&gt; #####<br/>&gt; Test failures:<br/>&gt; ~~ ../ext/File-Find/t/taint.t ..................................<br/>&gt; FAILED Non-zero exit status: 2 Bad plan. You planned 45 tests but ran<br/>&gt; 1.<br/>&gt; [stdio] -Duseithreads -Doptimize=&quot;-O2 -pipe -fstack-protector -fno-<br/>&gt; strict-aliasing&quot; -Dcc=&quot;gcc&quot; -Duselongdouble DEBUGGING<br/>&gt; #####<br/>&gt; <br/>&gt; Here it is taint.t that is experiencing failures; the patch applied<br/>&gt; dealt with find.t.<br/>&gt; <br/>&gt; I doubt that the particular ./Configure options had anything to do<br/>&gt; with the failure. The smokecurrent.log didn&#39;t have any more<br/>&gt; information than is visible at the URL cited above.<br/>&gt; <br/>&gt; Needs further investigation.<br/>&gt; <br/>&gt; Thank you very much.<br/><br/>Has this happened again since then?<br/><br/>It might be due to something unrelated.<br/><br/>Tony<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133771<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253700.html Wed, 13 Feb 2019 23:38:58 +0000 [perl #133781] Clarify DOC for split. Section about splitting emptystring by Tony Cook via RT On Sun, 20 Jan 2019 13:19:46 -0800, davidnicol@gmail.com wrote:<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; &gt; print map{ defined? &quot;YES&quot; :&quot;NO&quot;} split(&#39;b&#39;, &quot;b&quot;); # NOTHING IS PRINTED<br/>&gt; &gt;<br/>&gt; <br/>&gt; It initially seems like this should have printed a YES for an empty field<br/>&gt; at the beginning.<br/>&gt; <br/>&gt; The documentation for split doesn&#39;t mention that a string matching the<br/>&gt; delimiter will yield an empty list, aside from that this behavior is<br/>&gt; implied by the bit about trailing empty fields being dropped -- which seems<br/>&gt; buried in the discussion of the limit argument, and therefore not clearly<br/>&gt; controlling in the fact of the more clearly stated &quot;An empty leading field<br/>&gt; is produced when there is a positive-width match at the beginning of EXPR.&quot;<br/><br/>The thing is this behaviour is controlled by LIMIT:<br/><br/> $ perl -MData::Dumper -e &#39;print Dumper([ split /b/, &quot;b&quot; ])&#39;<br/> $VAR1 = [];<br/> $ perl -MData::Dumper -e &#39;print Dumper([ split /b/, &quot;b&quot;, 2 ])&#39;<br/> $VAR1 = [<br/> &#39;&#39;,<br/> &#39;&#39;<br/> ];<br/> $ perl -MData::Dumper -e &#39;print Dumper([ split /b/, &quot;b&quot;, -1 ])&#39;<br/> $VAR1 = [<br/> &#39;&#39;,<br/> &#39;&#39;<br/> ];<br/><br/>so I think it needs to stay with the LIMIT discussion.<br/><br/>The documentation is fairly explicit that all fields might be dropped with a zero limit:<br/><br/>... if all fields are empty, then all fields are considered to<br/>be trailing (and are thus stripped in this case)<br/><br/>&gt; I suggest throwing yet another clause in there, to give<br/>&gt; <br/>&gt; An empty leading field (which will probably get dropped when it is all<br/>&gt; there is, see below) is produced when there is a positive-width match at<br/>&gt; the beginning of EXPR.<br/><br/>I think this case is well covered by the above.<br/><br/>I&#39;ll close this ticket next week(ish) unless there&#39;s an objection.<br/><br/>Tony<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133781<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253699.html Wed, 13 Feb 2019 22:47:36 +0000 Re: [perl #132964] Missing newSVsv_nomg macro variant by pali On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:<br/>&gt; On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:<br/>&gt; &gt; And here is patch which makes sv_mortalcopy_flags() function public.<br/>&gt; <br/>&gt; +=for apidoc sv_mortalcopy_flags<br/>&gt; +<br/>&gt; +Like C&lt;sv_mortalcopy&gt;, but the extra C&lt;flags&gt; are passed to the<br/>&gt; +C&lt;sv_setsv_flags&gt;.<br/>&gt; +<br/>&gt; <br/>&gt; SV_GMAGIC is also meaningful for sv_mortalcopy_flags().<br/><br/>So... any suggestion how to improve documentation?<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253698.html Wed, 13 Feb 2019 19:16:12 +0000 [perl #133737] Build-time failures with PERL_GLOBAL_STRUCT andPERL_GLOBAL_STRUCT_PRIVATE by Jarkko Hietaniemi via RT [Karl found me gathering dust in a closet]<br/><br/>So yes, the global struct config was created for Symbian, which is dead <br/>as a dodo. The probability of still existing Symbian phones getting <br/>Perl installed is extremely low.<br/><br/>But more generally, the config was not Symbian-specific as such.<br/>It was created to cover for a limitation in Symbian, and that was<br/>&quot;shared libraries shall not have writeable data&quot; (they could have<br/>data, but only read-only). In more modern operating systems the<br/>writeable data sections of shared libraries are copy-on-write<br/><br/>The global struct is a bit misleading as terms go: what it does is that <br/>it pulls all the global data into a single struct, which can then be <br/>heap-allocated in main, and just passed around. So it is &quot;a struct for <br/>globals&quot;, not a &quot;global&quot; &quot;struct&quot;. The feature comes in two flavors,<br/>vanilla and PRIVATE,the latter of which is really strict: it leaves<br/>not even the global struct visible, but instead a function call<br/>through which you can access the the struct. (The description<br/>I wrote (I think) for perlguts is still good.)<br/><br/>I still find the config useful as a cleanliness exercise: do we have a <br/>good enough understanding and tracking of the global data so that we<br/>can move all of it to heap, making the shared library as &quot;pure&quot; as possible.<br/>But then again, as the creator of the feature I am biased.<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133737<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253697.html Wed, 13 Feb 2019 19:04:21 +0000 Re: [perl #131683] Encode::ONLY_PRAGMA_WARNINGS in$PerlIO::encoding::fallback by pali On Tuesday 12 February 2019 20:54:11 Tony Cook via RT wrote:<br/>&gt; On Tue, 12 Feb 2019 07:46:22 -0800, pali@cpan.org wrote:<br/>&gt; &gt; On Thursday 07 February 2019 16:05:40 pali@cpan.org wrote:<br/>&gt; &gt; &gt; On Tuesday 22 January 2019 09:38:38 pali@cpan.org wrote:<br/>&gt; &gt; &gt; &gt; On Monday 21 January 2019 15:03:02 Leon Timmermans via RT wrote:<br/>&gt; &gt; &gt; &gt; &gt; On Mon, Jan 21, 2019 at 6:51 PM &lt;pali@cpan.org&gt; wrote:<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ...and apply remaining<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; PerlIO::encoding patch?<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Can you specify which of the patches attached to this RT is<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; the one still under consideration?<br/>&gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; 0002-PerlIO-encoding-Use-Encode-ONLY_PRAGMA_WARNINGS-in-f.patch<br/>&gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; All other patches are part of Encode, and therefore applied.<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; Can you add a perldelta entry?<br/>&gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; I do not know where is correct place to put entries, nor what is<br/>&gt; &gt; &gt; &gt; correct<br/>&gt; &gt; &gt; &gt; formatting... But entry could contain something like this:<br/>&gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; ===<br/>&gt; &gt; &gt; &gt; Modules PerlIO::encoding and Encode were fixed to respect state of<br/>&gt; &gt; &gt; &gt; utf8<br/>&gt; &gt; &gt; &gt; pragma warnings when processing filehandle with :encoding layer.<br/>&gt; &gt; &gt; &gt; ===<br/>&gt; &gt; &gt;<br/>&gt; &gt; &gt; Leon, it is enough?<br/>&gt; &gt; <br/>&gt; &gt; PING<br/>&gt; <br/>&gt; Do you mean the patch:<br/>&gt; <br/>&gt; - Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::STOP_AT_PARTIAL();<br/>&gt; + Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::ONLY_PRAGMA_WARNINGS()|Encode::STOP_AT_PARTIAL();<br/>&gt; <br/><br/>Yes.<br/><br/>&gt; which fails a test:<br/>&gt; <br/>&gt; ../ext/PerlIO-encoding/t/fallback.t (Wstat: 256 Tests: 10 Failed: 1)<br/>&gt; Failed test: 2<br/>&gt; Non-zero exit status: 1<br/><br/>It started failing? Ah :-( IIRC it worked when I created it year ago.<br/><br/>I will look at it...<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253696.html Wed, 13 Feb 2019 08:36:41 +0000 [perl #133660] goto refcount increased by one when using goto by Tony Cook via RT On Thu, 07 Feb 2019 06:46:10 -0800, todd.e.rinaldo@gmail.com wrote:<br/>&gt; On Tue, 05 Feb 2019 20:42:46 -0800, tonyc wrote:<br/>&gt; &gt; On Tue, 20 Nov 2018 08:14:16 -0800, todd.e.rinaldo@gmail.com wrote:<br/>&gt; &gt; &gt; The only other action I can see here is to make sure we have a test<br/>&gt; &gt; &gt; for this. I need to look into the tests some more. The tests added in<br/>&gt; &gt; &gt; that commit are a skip and I&#39;m not clear if we&#39;ll detect the refcount<br/>&gt; &gt; &gt; issue the next time this happens.<br/>&gt; &gt; &gt; <br/>&gt; &gt; &gt; I&#39;ll try to check them later this week.<br/>&gt; &gt; <br/>&gt; &gt; Something like the attached?<br/>&gt; &gt; <br/>&gt; <br/>&gt; That&#39;s it! <br/>&gt; <br/>&gt; Fails on maint-5.26 as expected:<br/>&gt; <br/>&gt; # Failed test 142 - check goto core sub doesn&#39;t leak at ./test.pl line 1059<br/>&gt; # got &quot;not ok&quot;<br/>&gt; # expected &quot;ok&quot;<br/>&gt; # PROG: <br/>&gt; # <br/>&gt; # # done this way to avoid overloads for all of svleak.t<br/>&gt; # use B;<br/>&gt; # BEGIN {<br/>&gt; # *CORE::GLOBAL::open = sub (*;$@) {<br/>&gt; # goto \&amp;CORE::open;<br/>&gt; # };<br/>&gt; # }<br/>&gt; # <br/>&gt; # my $refcount;<br/>&gt; # {<br/>&gt; # open(my $fh, &#39;&lt;&#39;, &#39;TEST&#39;);<br/>&gt; # my $sv = B::svref_2object($fh);<br/>&gt; # print $sv-&gt;REFCNT == 1 ? &quot;ok&quot; : &quot;not ok&quot;;<br/>&gt; # }<br/>&gt; # STATUS: 0<br/>&gt; <br/>&gt; And passes on maint-5.28 <br/>&gt; <br/>&gt; ok 150 - check goto core sub doesn&#39;t leak<br/>&gt; <br/>&gt; I&#39;ll let you do the honors. <br/><br/>Applied as ac6d2595875ea2813009c120fd54eb70c9ed2b0a.<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=133660<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253695.html Wed, 13 Feb 2019 05:27:08 +0000 [perl #131683] Encode::ONLY_PRAGMA_WARNINGS in$PerlIO::encoding::fallback by Tony Cook via RT On Tue, 12 Feb 2019 07:46:22 -0800, pali@cpan.org wrote:<br/>&gt; On Thursday 07 February 2019 16:05:40 pali@cpan.org wrote:<br/>&gt; &gt; On Tuesday 22 January 2019 09:38:38 pali@cpan.org wrote:<br/>&gt; &gt; &gt; On Monday 21 January 2019 15:03:02 Leon Timmermans via RT wrote:<br/>&gt; &gt; &gt; &gt; On Mon, Jan 21, 2019 at 6:51 PM &lt;pali@cpan.org&gt; wrote:<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; ...and apply remaining<br/>&gt; &gt; &gt; &gt; &gt; &gt; &gt; PerlIO::encoding patch?<br/>&gt; &gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; &gt; Can you specify which of the patches attached to this RT is<br/>&gt; &gt; &gt; &gt; &gt; &gt; the one still under consideration?<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; 0002-PerlIO-encoding-Use-Encode-ONLY_PRAGMA_WARNINGS-in-f.patch<br/>&gt; &gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; &gt; All other patches are part of Encode, and therefore applied.<br/>&gt; &gt; &gt; &gt;<br/>&gt; &gt; &gt; &gt; Can you add a perldelta entry?<br/>&gt; &gt; &gt;<br/>&gt; &gt; &gt; I do not know where is correct place to put entries, nor what is<br/>&gt; &gt; &gt; correct<br/>&gt; &gt; &gt; formatting... But entry could contain something like this:<br/>&gt; &gt; &gt;<br/>&gt; &gt; &gt; ===<br/>&gt; &gt; &gt; Modules PerlIO::encoding and Encode were fixed to respect state of<br/>&gt; &gt; &gt; utf8<br/>&gt; &gt; &gt; pragma warnings when processing filehandle with :encoding layer.<br/>&gt; &gt; &gt; ===<br/>&gt; &gt;<br/>&gt; &gt; Leon, it is enough?<br/>&gt; <br/>&gt; PING<br/><br/>Do you mean the patch:<br/><br/>- Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::STOP_AT_PARTIAL();<br/>+ Encode::PERLQQ()|Encode::WARN_ON_ERR()|Encode::ONLY_PRAGMA_WARNINGS()|Encode::STOP_AT_PARTIAL();<br/><br/><br/>which fails a test:<br/><br/>../ext/PerlIO-encoding/t/fallback.t (Wstat: 256 Tests: 10 Failed: 1)<br/> Failed test: 2<br/> Non-zero exit status: 1<br/><br/>Tony<br/><br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=131683<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253694.html Wed, 13 Feb 2019 04:54:18 +0000 [perl #132964] Missing newSVsv_nomg macro variant by Tony Cook via RT On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:<br/>&gt; And here is patch which makes sv_mortalcopy_flags() function public.<br/><br/>+=for apidoc sv_mortalcopy_flags<br/>+<br/>+Like C&lt;sv_mortalcopy&gt;, but the extra C&lt;flags&gt; are passed to the<br/>+C&lt;sv_setsv_flags&gt;.<br/>+<br/><br/>SV_GMAGIC is also meaningful for sv_mortalcopy_flags().<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: open<br/>https://rt.perl.org/Ticket/Display.html?id=132964<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253693.html Wed, 13 Feb 2019 04:13:50 +0000 [perl #132964] Missing newSVsv_nomg macro variant by Tony Cook via RT On Thu, 07 Feb 2019 05:22:52 -0800, pali@cpan.org wrote:<br/>&gt; In attachment is implementation of newSVsv_nomg() variant macro which<br/>&gt; does not process get magic on input scalar.<br/><br/>Why not make SV_NOSTEAL significant for newSVsv_flags() ?<br/><br/>Otherwise it will be messy adding it in the future.<br/><br/>Tony<br/><br/>---<br/>via perlbug: queue: perl5 status: new<br/>https://rt.perl.org/Ticket/Display.html?id=132964<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2019/02/msg253692.html Wed, 13 Feb 2019 04:08:55 +0000