Skip Menu |
Report information
Id: 129950
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: manabe.hiroshi [at] gmail.com
Cc:
AdminCc:

Operating System: All
PatchStatus: (no value)
Severity: low
Type:
Perl Version: (no value)
Fixed In: 5.25.7



Subject: Some UTF-8 regular expression matches fail when read from file
Download (untitled) / with headers
text/plain 500b
You can reproduc the bug with the following procedure: 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; Output: not matched This happenes only when the string is read from a file handle and the second character is in the range of \x{80}-\x{ff}. Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}-\x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}-\x{e4}]$}.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 687b
On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote: Show quoted text
> You can reproduc the bug with the following procedure: > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > Output: not matched > > This happenes only when the string is read from a file handle and the > second character is in the range of \x{80}-\x{ff}. > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > \x{e4}]$}.
Sorry, the bug only reproduces itself when there is a set of parenthes, i.e. m{^(a|a\x{e4})$} etc.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 844b
On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote: Show quoted text
> On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
> > You can reproduc the bug with the following procedure: > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > > Output: not matched > > > > This happenes only when the string is read from a file handle and the > > second character is in the range of \x{80}-\x{ff}. > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > > \x{e4}]$}.
> > Sorry, the bug only reproduces itself when there is a set of > parenthes, i.e. m{^(a|a\x{e4})$} etc.
Sorry again, the correct unicode option for the step 2 was -Ci.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 4.7k
On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote: Show quoted text
> On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
> > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
> > > You can reproduc the bug with the following procedure: > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > > > Output: not matched > > > > > > This happenes only when the string is read from a file handle and the > > > second character is in the range of \x{80}-\x{ff}. > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > > > \x{e4}]$}.
> > > > Sorry, the bug only reproduces itself when there is a set of > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
> > Sorry again, the correct unicode option for the step 2 was -Ci.
This seems interesting: $ perl -Ci -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^(a\x{e4})$} ? "matched\n" : "not matched\n";' matched $ perl -Ci -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' not matched And with -Dr... dcollins@nightshade64:~/toolchain$ perl5.25.2-debug -D -Ci -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^(a\x{e4})$} ? "matched\n" : "not matched\n";' Debugging flag values: (see also -d) p Tokenizing and parsing (with v, displays parse stack) s Stack snapshots (with v, displays all stacks) l Context (loop) stack processing t Trace execution o Method and overloading resolution c String/numeric conversions P Print profiling info, source file input state m Memory and SV allocation f Format processing r Regular expression parsing and execution x Syntax tree dump u Tainting checks H Hash dump -- usurps values() X Scratchpad allocation D Cleaning up S Op slab allocation T Tokenising R Include reference counts of dumped variables (eg when using -Ds) J Do not s,t,P-debug (Jump over) opcodes within package DB v Verbose: use in conjunction with other flags C Copy On Write A Consistency checks on internal structures q quiet - currently only suppresses the 'EXECUTING' message M trace smart match resolution B dump suBroutine definitions, including special Blocks like BEGIN L trace some locale setting information--for Perl core development i trace PerlIO layer processing EXECUTING... matched dcollins@nightshade64:~/toolchain$ perl5.25.2-debug -Dr -Ci -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^(a\x{e4})$} ? "matched\n" : "not matched\n";' Compiling REx "^(a\x{e4})$" rarest char ▒ at 1 Final program: 1: SBOL /^/ (2) 2: OPEN1 (4) 4: EXACT <a\x{e4}> (6) 6: CLOSE1 (8) 8: SEOL (9) 9: END (0) anchored "a%x{e4}"$ at 0 (checking anchored noscan) anchored(SBOL) minlen 2 Enabling $` $& $' support (0x7). EXECUTING... Matching REx "^(a\x{e4})$" against "a%x{e4}" UTF-8 string... Intuit: trying to determine minimum start position... rarest char ▒ at 2 Looking for check substr at fixed offset 0... Intuit: Successfully guessed: match at offset 0 0 <> <a%x{e4}> | 0| 1:SBOL /^/(2) 0 <> <a%x{e4}> | 0| 2:OPEN1(4) 0 <> <a%x{e4}> | 0| 4:EXACT <a\x{e4}>(6) 3 <a%x{e4}> <> | 0| 6:CLOSE1(8) 3 <a%x{e4}> <> | 0| 8:SEOL(9) 3 <a%x{e4}> <> | 0| 9:END(0) Match successful! matched Freeing REx: "^(a\x{e4})$" dcollins@nightshade64:~/toolchain$ perl5.25.2-debug -Dr -Ci -e 'open IN, "<", "foo.txt"; $_ = <IN>; print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' Compiling REx "^(a|a\x{e4})$" rarest char at 0 rarest char a at 0 Final program: 1: SBOL /^/ (2) 2: OPEN1 (4) 4: EXACT <a> (6) 6: TRIE-EXACT[\xE4] (10) <> <\344> 10: CLOSE1 (12) 12: SEOL (13) 13: END (0) anchored "a" at 0 floating ""$ at 1..2 (checking anchored noscan) anchored(SBOL) minlen 1 Enabling $` $& $' support (0x7). EXECUTING... Matching REx "^(a|a\x{e4})$" against "a%x{e4}" UTF-8 string... Intuit: trying to determine minimum start position... rarest char at 0 rarest char a at 0 Looking for check substr at fixed offset 0... Intuit: Successfully guessed: match at offset 0 0 <> <a%x{e4}> | 0| 1:SBOL /^/(2) 0 <> <a%x{e4}> | 0| 2:OPEN1(4) 0 <> <a%x{e4}> | 0| 4:EXACT <a>(6) 1 <a> <%x{e4}> | 0| 6:TRIE-EXACT[\xE4](10) | 0| matched empty string... 1 <a> <%x{e4}> | 0| 10:CLOSE1(12) 1 <a> <%x{e4}> | 0| 12:SEOL(13) | 0| failed... Match failed not matched Freeing REx: "^(a|a\x{e4})$" Unicode errors aside, is the TRIE optimization getting this wrong? -- Respectfully, Dan Collins
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote: Show quoted text
> On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
> > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
> > > You can reproduc the bug with the following procedure: > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > > > Output: not matched > > > > > > This happenes only when the string is read from a file handle and the > > > second character is in the range of \x{80}-\x{ff}. > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > > > \x{e4}]$}.
> > > > Sorry, the bug only reproduces itself when there is a set of > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
> > Sorry again, the correct unicode option for the step 2 was -Ci.
The string doesn't need to be from a file: $ ./perl -e '$_ = "a\xE4"; utf8::upgrade($_); print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' not matched (blead perl) The match is failing around like 5611 of regexec.c: if ( trie->bitmap && (NEXTCHR_IS_EOS || !TRIE_BITMAP_TEST(trie, nextchr))) { if (trie->states[ state ].wordnum) { DEBUG_EXECUTE_r( Perl_re_exec_indentf( aTHX_ "%smatched empty string...%s\n", depth, PL_colors[4], PL_colors[5]) ); At this point nextchr has the first byte of the UTF-8 encoded \xE4 (0xc3). Tony
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #129950] Some UTF-8 regular expression matches fail when read from file
To: Tony Cook via RT <perlbug-followup [...] perl.org>
CC: perl5-porters [...] perl.org
Date: Tue, 25 Oct 2016 11:12:30 +0100
Download (untitled) / with headers
text/plain 1.8k
On Mon, Oct 24, 2016 at 03:57:15PM -0700, Tony Cook via RT wrote: Show quoted text
> On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote:
> > On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
> > > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
> > > > You can reproduc the bug with the following procedure: > > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > > > > Output: not matched > > > > > > > > This happenes only when the string is read from a file handle and the > > > > second character is in the range of \x{80}-\x{ff}. > > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > > > > \x{e4}]$}.
> > > > > > Sorry, the bug only reproduces itself when there is a set of > > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
> > > > Sorry again, the correct unicode option for the step 2 was -Ci.
> > The string doesn't need to be from a file: > > $ ./perl -e '$_ = "a\xE4"; utf8::upgrade($_); print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' > not matched > > (blead perl) > > The match is failing around like 5611 of regexec.c: > > if ( trie->bitmap > && (NEXTCHR_IS_EOS || !TRIE_BITMAP_TEST(trie, nextchr))) > { > if (trie->states[ state ].wordnum) { > DEBUG_EXECUTE_r( > Perl_re_exec_indentf( aTHX_ "%smatched empty string...%s\n", > depth, PL_colors[4], PL_colors[5]) > ); > > At this point nextchr has the first byte of the UTF-8 encoded \xE4 (0xc3).
I'm looking into this as we speak. -- I thought I was wrong once, but I was mistaken.
CC: Tony Cook via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Date: Tue, 25 Oct 2016 12:31:59 +0200
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #129950] Some UTF-8 regular expression matches fail when read from file
Download (untitled) / with headers
text/plain 2.1k
On 25 October 2016 at 12:12, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Mon, Oct 24, 2016 at 03:57:15PM -0700, Tony Cook via RT wrote:
>> On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote:
>> > On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
>> > > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
>> > > > You can reproduc the bug with the following procedure: >> > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä >> > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print >> > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; >> > > > Output: not matched >> > > > >> > > > This happenes only when the string is read from a file handle and the >> > > > second character is in the range of \x{80}-\x{ff}. >> > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- >> > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- >> > > > \x{e4}]$}.
>> > > >> > > Sorry, the bug only reproduces itself when there is a set of >> > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
>> > >> > Sorry again, the correct unicode option for the step 2 was -Ci.
>> >> The string doesn't need to be from a file: >> >> $ ./perl -e '$_ = "a\xE4"; utf8::upgrade($_); print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' >> not matched >> >> (blead perl) >> >> The match is failing around like 5611 of regexec.c: >> >> if ( trie->bitmap >> && (NEXTCHR_IS_EOS || !TRIE_BITMAP_TEST(trie, nextchr))) >> { >> if (trie->states[ state ].wordnum) { >> DEBUG_EXECUTE_r( >> Perl_re_exec_indentf( aTHX_ "%smatched empty string...%s\n", >> depth, PL_colors[4], PL_colors[5]) >> ); >> >> At this point nextchr has the first byte of the UTF-8 encoded \xE4 (0xc3).
> > I'm looking into this as we speak.
I was going to look into it later as well. Let me know how far you get. We used to preload the bitmap with the first byte of the unicode representation of the string, but I guess I can leave it to you. Let me know otherwise. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Subject: Re: [perl #129950] Some UTF-8 regular expression matches fail when read from file
To: demerphq <demerphq [...] gmail.com>
CC: Tony Cook via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Date: Tue, 25 Oct 2016 12:45:28 +0100
Download (untitled) / with headers
text/plain 2.6k
On Tue, Oct 25, 2016 at 12:31:59PM +0200, demerphq wrote: Show quoted text
> On 25 October 2016 at 12:12, Dave Mitchell <davem@iabyn.com> wrote:
> > On Mon, Oct 24, 2016 at 03:57:15PM -0700, Tony Cook via RT wrote:
> >> On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote:
> >> > On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
> >> > > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
> >> > > > You can reproduc the bug with the following procedure: > >> > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä > >> > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print > >> > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; > >> > > > Output: not matched > >> > > > > >> > > > This happenes only when the string is read from a file handle and the > >> > > > second character is in the range of \x{80}-\x{ff}. > >> > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- > >> > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- > >> > > > \x{e4}]$}.
> >> > > > >> > > Sorry, the bug only reproduces itself when there is a set of > >> > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
> >> > > >> > Sorry again, the correct unicode option for the step 2 was -Ci.
> >> > >> The string doesn't need to be from a file: > >> > >> $ ./perl -e '$_ = "a\xE4"; utf8::upgrade($_); print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' > >> not matched > >> > >> (blead perl) > >> > >> The match is failing around like 5611 of regexec.c: > >> > >> if ( trie->bitmap > >> && (NEXTCHR_IS_EOS || !TRIE_BITMAP_TEST(trie, nextchr))) > >> { > >> if (trie->states[ state ].wordnum) { > >> DEBUG_EXECUTE_r( > >> Perl_re_exec_indentf( aTHX_ "%smatched empty string...%s\n", > >> depth, PL_colors[4], PL_colors[5]) > >> ); > >> > >> At this point nextchr has the first byte of the UTF-8 encoded \xE4 (0xc3).
> > > > I'm looking into this as we speak.
> > I was going to look into it later as well. Let me know how far you get.
Not far as it turns out. The failing code has TRIE_BITMAP_TEST() returning false, while good code like $_ = "a\x64"; print "match\n" if m{^(a|a\x{64})$}; doesn't. At which point I got distracted and haven't looked further. You're probably a better choice than me to take this further :-) -- The Enterprise's efficient long-range scanners detect a temporal vortex distortion in good time, allowing it to be safely avoided via a minor course correction. -- Things That Never Happen in "Star Trek" #21
Date: Thu, 27 Oct 2016 14:03:48 +0200
CC: Tony Cook via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #129950] Some UTF-8 regular expression matches fail when read from file
Download (untitled) / with headers
text/plain 3.4k
On 25 October 2016 at 13:45, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Tue, Oct 25, 2016 at 12:31:59PM +0200, demerphq wrote:
>> On 25 October 2016 at 12:12, Dave Mitchell <davem@iabyn.com> wrote:
>> > On Mon, Oct 24, 2016 at 03:57:15PM -0700, Tony Cook via RT wrote:
>> >> On Sun Oct 23 21:48:55 2016, manabe.hiroshi@gmail.com wrote:
>> >> > On 2016-10月-23 日 21:44:35, manabe.hiroshi@gmail.com wrote:
>> >> > > On 2016-10月-23 日 21:23:20, manabe.hiroshi@gmail.com wrote:
>> >> > > > You can reproduc the bug with the following procedure: >> >> > > > 1. perl -CO -e 'print "a\x{e4}";' > foo.txt # aä >> >> > > > 2. perl -CI -e 'open IN, "<", "foo.txt"; $_ = <IN>; print >> >> > > > m{^a|a\x{e4}$} . "matched\n" : "not matched\n"; >> >> > > > Output: not matched >> >> > > > >> >> > > > This happenes only when the string is read from a file handle and the >> >> > > > second character is in the range of \x{80}-\x{ff}. >> >> > > > Curiously enough, the match succeeds if the regexp is m{^a|a[\x{e3}- >> >> > > > \x{e4}]$} or m{^a|a[\x{e4}-\x{e5}]$}, but not if it is m{^a|a[\x{e4}- >> >> > > > \x{e4}]$}.
>> >> > > >> >> > > Sorry, the bug only reproduces itself when there is a set of >> >> > > parenthes, i.e. m{^(a|a\x{e4})$} etc.
>> >> > >> >> > Sorry again, the correct unicode option for the step 2 was -Ci.
>> >> >> >> The string doesn't need to be from a file: >> >> >> >> $ ./perl -e '$_ = "a\xE4"; utf8::upgrade($_); print m{^(a|a\x{e4})$} ? "matched\n" : "not matched\n";' >> >> not matched >> >> >> >> (blead perl) >> >> >> >> The match is failing around like 5611 of regexec.c: >> >> >> >> if ( trie->bitmap >> >> && (NEXTCHR_IS_EOS || !TRIE_BITMAP_TEST(trie, nextchr))) >> >> { >> >> if (trie->states[ state ].wordnum) { >> >> DEBUG_EXECUTE_r( >> >> Perl_re_exec_indentf( aTHX_ "%smatched empty string...%s\n", >> >> depth, PL_colors[4], PL_colors[5]) >> >> ); >> >> >> >> At this point nextchr has the first byte of the UTF-8 encoded \xE4 (0xc3).
>> > >> > I'm looking into this as we speak.
>> >> I was going to look into it later as well. Let me know how far you get.
> > Not far as it turns out. The failing code has TRIE_BITMAP_TEST() returning > false, while good code like > > $_ = "a\x64"; > print "match\n" if m{^(a|a\x{64})$}; > > doesn't. > At which point I got distracted and haven't looked further. You're probably > a better choice than me to take this further :-)
Fixed. This ticket can be closed. commit da42332b10691ba7af7550035ffc7f46c87e4e66 Author: Yves Orton <demerphq@gmail.com> Date: Thu Oct 27 13:52:24 2016 +0200 regcomp.c: fix perl #129950 - fix firstchar bitmap under utf8 with prefix optimisation The trie code contains a number of sub optimisations, one of which extracts common prefixes from alternations, and another which isa bitmap of the possible matching first chars. The bitmap needs to contain the possible first octets of the string which the trie can match, and for codepoints which might have a different first octet under utf8 or non-utf8 need to register BOTH codepoints. So for instance in the pattern (?:a|a\x{E4}) we should restructure this as a(|\x{E4), and the bitmap for the trie should contain both \x{E4} AND \x{C3} as \x{C3} is the first byte of \x{EF} expressed as utf8. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Download (untitled) / with headers
text/plain 313b
Thank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been resolved. Perl 5.26.0 may be downloaded via: https://metacpan.org/release/XSAWYERX/perl-5.26.0 If you find that the problem persists, feel free to reopen this ticket.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org