Adam Harvey wrote: > On 23 July 2015 at 11:47, Christoph Becker <cmbecke...@gmx.de> wrote: > <snip great explanation, thanks> >> Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit). >> That would mean, however, to add yet another ini setting, of which >> there are already so many. > > I'm not a big fan of that, although it's at least in the spirit of > what configuration settings are meant to be used for. > > What if we added the PCRE_ERROR_JIT_STACKLIMIT error constant to those > exposed to userland so that it's more easily noticed via > preg_last_error(), and adding a modifier that can be used to disable > the JIT on a per-pattern basis (by setting PCRE_NO_START_OPTIMIZE, > which admittedly disables other stuff too, but at least the regex will > run)? At least then users could check the error when the regex fails > and re-run the regex without the JIT if they chose to.
Yes, that would be an option. I'm not sure if we need to touch PCRE_NO_START_OPTIMIZE (or if it would even help); simply not calling pcre_study() respectively not passing the studied extra data (second argument) to pcre_exec() should be sufficient. > How likely is the average user to hit this, do you think? I don't know. The libpcre man pages say: | JIT uses far less memory for recursion than the interpretive code, | and a maximum stack size of 512K to 1M should be more than enough for | any pattern. Of course, a hard-coded 512K or even more would be rather much. The default stack size (32K) for the regex in the test script of #70110 would be sufficient, if the subject is repeated only about 2000 times, but that doesn't say much (the preg_match() is rather contrived). Anyway, that shows that it's not only the pattern that's relevant for the needed JIT stack space, but also the subject string. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
