Am 25.2.2013 um 17:45 schrieb Johannes Schlüter <johan...@schlueters.de>:
> On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote: >> p.s.: There is no reason why not to fix this in this way, I think, as >> you can test at how may iterations the stack will overflow and set the >> limit near to this maximum. Which is exactly what we have already >> today, only without possible crashes. > > For one the stack frames aren't always the same size on all nesting > levels, depending on what's exactly happening. > > There have neen different discussions about this in the past. One I > could finde first was > Vote for Zend Deep Stack Prevention (ZDSP) > http://news.php.net/php.internals/22011 > > In general reasons for not doing that were that we'd have a hard time > setting a good default for an counter-based approach, whereas an > approach checking the actual stack size would be too expensive. > > I however agree that with recent engine improvements, where infinite > recursion is harder to get one might rethink that. A name using "magic" > sounds inappropriate, though in any case. :-) Yes, but you can do an approximation. And in 99.999% of the cases 100 will be enough. I can hardly imagine a case where you need to do over 100 implicit function calls. They should fit in every normal stack size of servers today. This "ZDSP" is also checking very often (at every single opcode execution) while my patch checks only in a more rare - in little scripts nearly never - called function: a negligible cost. Right. As far I see the implicit function calls are also the only possibility left today out to let php crash due to a stack overflow beside pcre-functions... Then max_implicit_function_calls would be a good name? Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
