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
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Oct 12, 2015

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

Searchable as RT126328$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT 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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT 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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 12, 2015

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT 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.

@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.