This was introduced as 50 by 6bda09f (Yves, 2006-10-04), made compile-time overridable by d56b301 (Rafael, 2007-02-14), bumped to 1000 by 4b196cd (Yves, 2007-02-15), and then dropped to 10 by ba6840f (Yves, 2016-03-06 as part of #14935). There are brief mentions in perlre under (?PARNO) and (??{ expr }):
Recursing deeply without consuming any input string will
also result in a fatal error. The depth at which that happens is
compiled into perl, so it can be changed with a custom build.
[...]
Executing a postponed regular expression too many times without
consuming any input string will also result in a fatal error.
.. but once we hit a GOSUB it looks like every additional GOSUB or EVAL ("postponed" or not) bumps the count, so as of now we get:
% perl -wle '"foo" =~ m{(?&FOO)(?(DEFINE)(?<FOO>
(?{1}) (?{1}) (?{1}) (?{1}) (?{1})
(?{1}) (?{1}) (?{1}) (?{1}) (?{1})
(?{1})
foo
))}x'
EVAL without pos change exceeded limit in regex at -e line 1.
%
This behaviour breaks Regexp::Debugger for quite trivial cases, which is a shame.
I consider it wrong that this recursion check is any more than a warning (as for sub recursion); if there's a good reason for it to be fatal, I think it really must be controllable without having to recompile perl. But the first question is whether it is actually checking the right thing - should it be treating normal (?{...}) evals as a candidate for bumping the recursion depth at all?
@demerphq can you clarify if this check was intended to kill patterns like the above?
Hugo
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4