Regex stores wrong value in $1, $^N etc, thoroughly corrupting parsers #17052
Comments
From @jlokierCreated by @jlokierHi, The following short Perl program shows the error: sub S { "A" =~ /(.)(?{})/; } Output should be: x Actual output is: x This is because the value stored in $1 is incorrect. It's not even part of the matched string! If we change the As you can imagine, breaking Removing the (?{}) from the inner regex in S() stops this bug from I've verified this in Perl 5.22.1, Perl 5.26.1 and Perl 5.28.1, hoping Now I am struggling to figure out how to rewrite all my parsers, Any advice on a clean workaround would be welcome. (The obvious advice to use //g instead of /(...)*/ does work for Thanks, Perl Info |
From @tonycozOn Tue, 18 Jun 2019 13:37:38 -0700, jamie wrote:
I'm not suggesting this isn't a bug, but has it ever worked the way you expect? I tried perls back to 5.10: $ ~/perl/5.10.0-debug/bin/perl ../134209.pl A non-debug perl 5.10 produced corrupted output and an out of memory error. $ ~/perl/5.12.0/bin/perl ../134209.pl $ ~/perl/5.14.2-debug/bin/perl ../134209.pl $ ~/perl/5.16.3/bin/perl ../134209.pl Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jlokierTony Cook via RT wrote:
No, I wouldn't have expected everything to be fine prior to Perl 5.18. I had thought regex variables and (?{...}) blocks in general to be From perl5180delta(1): - The implementation of code blocks in regular expressions, such as - Lexical variables are now sane as regards scope, recursion and So I've always thought lexical variables and scopes generally were Variables like $^N and $1 are so much more "straightforward" and So surprised, in fact, that I didn't notice with one parser alone, Best, |
Migrated from rt.perl.org#134209 (status was 'open')
Searchable as RT134209$
The text was updated successfully, but these errors were encountered: