Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66200
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP List Developers Mailing <internals@lists.php.net>
In-Reply-To: <BLU0-SMTP17590EBA81C73B80FBD2DC4E2F30@phx.gbl>
References: <BLU0-SMTP17590EBA81C73B80FBD2DC4E2F30@phx.gbl>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 25 Feb 2013 17:45:38 +0100
Message-ID: <1361810738.2376.74.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] About restricting the recursive implicit calls
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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. :-)

johannes