On Jul 24, 2015 3:32 PM, "David Zuelke" <d...@heroku.com> wrote: > > On 24.07.2015, at 09:33, Adam Harvey <ahar...@php.net> 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. > > But this might mean that patterns which previously worked, because no JIT was used, suddenly fail in existing code with a new error constant. Which I guess is a BC break.
Such things happened in the past with normal updates, both ways. Simple code changes, fixes etc may have led to changes in the stack usage. I can remember issues with some specific updates.
