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
(*SKIP) not triggering correctly #14979
Comments
From 0perlbugs@rexegg.com(*SKIP) should get triggered if the engine attempts to backtrack across it. Perhaps due to internal optimizations, (*SKIP) is not getting triggered in cases where backtracking across (*SKIP) is expected. === Case 1 === === Case 2 === |
From 0perlbugs@rexegg.comThe Case 2 behavior is also inconsistent with the ever so popular (*SKIP)(*FAIL) construct, where the engine fires the (*SKIP) even when there is nothing to backtrack to the left of it. For instance, if ('tatatiti' =~ /tata(*SKIP)(*FAIL)|.{4}/ ) { print "\$&=\"$&\"\n"; } |
From [Unknown Contact. See original ticket]The Case 2 behavior is also inconsistent with the ever so popular (*SKIP)(*FAIL) construct, where the engine fires the (*SKIP) even when there is nothing to backtrack to the left of it. For instance, if ('tatatiti' =~ /tata(*SKIP)(*FAIL)|.{4}/ ) { print "\$&=\"$&\"\n"; } |
From 0perlbugs@rexegg.comCase 2 is also inconsistent with where (*SKIP) fires (correctly IMO) even though there is nothing to backtrack to the left of it, eventually matching ABC |
From [Unknown Contact. See original ticket]Case 2 is also inconsistent with where (*SKIP) fires (correctly IMO) even though there is nothing to backtrack to the left of it, eventually matching ABC |
From @demerphqOn 12 October 2015 at 02:40, Rex <perlbug-followup@perl.org> wrote:
Yes, other optimizations kick in which mean that in some cases it does
The mandatrory minimal string in the pattern is aard. If we do not see
Again this an interaction with the minimal substring optimization. We When I originally implemented these directives I decided that they I think probably the bestway to fix this is to have a modifier flag Alternatively, maybe I just didnt make the right decision about which I was going to say that you can stick (??{ "" }) in your pattern to I will try to follow up on this stuff when I get time. Yves -- |
The RT System itself - Status changed from 'new' to 'open' |
From 0perlbugs@rexegg.comHi Yves, Thank you very much for looking into this! Let me preface this by saying that I find it wonderful that these verbs are even in the language. Thank you for this facility and all your hard work. A few weeks ago (*SKIP) and (*PRUNE) were picked up by Python's alternate `regex` package, so their influence is slowly spreading. I'm a little sad about the crippling of (*SKIP) by optimizations. Could this be a case where it's less important to save time by studying the pattern than to preserve the intent expressed by the pattern writer? You mentioned two possible directions: disabling optimizations for (*SKIP), or introducing a verb to do that. If you choose the second direction, may I suggest (*NO_START_OPT) ? Usually PCRE regex borrows from Perl, but there have been occasions when the reverse has taken place: I'm preparing a long page to explain backtracking control verbs in the three engines that support them (Perl, PCRE and to a lesser extent Python via the alternate regex package), and that's how I happened to notice these behaviors. With many thanks and kindest regards, Rex |
Migrated from rt.perl.org#126327 (status was 'open')
Searchable as RT126327$
The text was updated successfully, but these errors were encountered: