Skip Menu |
Report information
Id: 126328
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: 0perlbugs [at] rexegg.com
Cc:
AdminCc:

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



Subject: (*COMMIT) fires inconsistently when another backtracking control verb occurs to its right
Download (untitled) / with headers
text/plain 967b
When another backtracking control verb is passed after a (*COMMIT), if that verb is backtracked into, the logical behavior (also adopted by PCRE) is that that verb fires, and (*COMMIT) doesn't. This seems to be the case with (*SKIP) but not (*PRUNE), === Case 1: just (*COMMIT) === if ('123ABC' =~ /123(*COMMIT)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } # (*COMMIT) fires as expected: no overall match. === Case 2: (*COMMIT) followed by (*SKIP) === if ('123ABC' =~ /1(*COMMIT)23(*SKIP)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } # As expected, (*COMMIT) does NOT fire but (*SKIP) does: the match is ABC === Case 3: (*COMMIT) followed by (*PRUNE) === if ('123ABC' =~ /1(*COMMIT)23(*PRUNE)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } # Unlike the previous case, (*COMMIT) fires despite (*PRUNE) being backtracked into first. As a result, there is no match. # The expected match, with (*PRUNE) firing, is 23A
To: Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Date: Mon, 12 Oct 2015 17:50:06 +0200
Subject: Re: [perl #126328] (*COMMIT) fires inconsistently when another backtracking control verb occurs to its right
Download (untitled) / with headers
text/plain 1.3k
Thanks for the report. I will investigate a bit before I say anything. Yves On 12 October 2015 at 06:50, Rex <perlbug-followup@perl.org> wrote: Show quoted text
> # New Ticket Created by Rex > # Please include the string: [perl #126328] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=126328 > > > > When another backtracking control verb is passed after a (*COMMIT), if that verb is backtracked into, the logical behavior (also adopted by PCRE) is that that verb fires, and (*COMMIT) doesn't. This seems to be the case with (*SKIP) but not (*PRUNE), > > === Case 1: just (*COMMIT) === > if ('123ABC' =~ /123(*COMMIT)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } > # (*COMMIT) fires as expected: no overall match. > > === Case 2: (*COMMIT) followed by (*SKIP) === > if ('123ABC' =~ /1(*COMMIT)23(*SKIP)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } > # As expected, (*COMMIT) does NOT fire but (*SKIP) does: the match is ABC > > === Case 3: (*COMMIT) followed by (*PRUNE) === > if ('123ABC' =~ /1(*COMMIT)23(*PRUNE)B|.{3}/ ) { print "\$&='$&'\n"; } else { print "No match\n"; } > # Unlike the previous case, (*COMMIT) fires despite (*PRUNE) being backtracked into first. As a result, there is no match. > # The expected match, with (*PRUNE) firing, is 23A >
-- perl -Mre=debug -e "/just|another|perl|hacker/"
RT-Send-CC: demerphq [...] gmail.com, perl5-porters [...] perl.org
Thank you. Please let me know if there are tests you'd like me to run in case it's system-related.


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