On 21.03.2016, at 23:44, Anatol Belski <anatol....@belski.net> wrote: > > What I'm suggesting to do is using a bit finer comb checking with the real > life situations. Fe what would be the win for the user, either having to > enable JIT by hand, or to disable it in a rare case. Currently, as for me, > the latter seems still to be a more feasible option. At some point some due > consideration could be reached, but I don't see the today's point as such. > As long as we still handle over 99% of the usage cases with a simple JIT > stack increase, it is IMHO more than balanced. The option of falling back to > no JIT could be still kept in mind as it's most likely won't cause any > compatibility issue.
Yeah no doubt. The trouble is that not always is the cause of the error very clear. I'd guess most code out there doesn't use preg_last_error() to figure out what went wrong and report that back, making it look like there simply was no match, so there's likely a lot of unknown cases, of which just some will emerge over time. What adds to the trouble is that it depends on the subject string, and not just on the pattern. So maybe people's existing tests won't catch it. How about defaulting JIT to off (or at least setting it to 0 in both the recommended dev and prod INIs that ship with PHP) until an automatic fallback has been implemented? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
