Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(*COMMIT) fires inconsistently when another backtracking control verb occurs to its right #14980

Open
p5pRT opened this issue Oct 12, 2015 · 4 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 12, 2015

Migrated from rt.perl.org#126328 (status was 'open')

Searchable as RT126328$

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2015

From 0perlbugs@rexegg.com

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

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2015

From @demerphq

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​:

# 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-archive.perl.org/perl5/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/"

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2015

From 0perlbugs@rexegg.com

Thank you. Please let me know if there are tests you'd like me to run in case it's system-related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants