Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.98 as permitted sender)
Message-ID: <BLU0-SMTP192F5092E7FAF349E58EF14E2F30@phx.gbl>
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
Disposition-Notification-To: bobwei9@hotmail.com
In-Reply-To: <1361810738.2376.74.camel@guybrush>
Date: Mon, 25 Feb 2013 17:56:34 +0100
CC: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <BLU0-SMTP17590EBA81C73B80FBD2DC4E2F30@phx.gbl> <1361810738.2376.74.camel@guybrush>
To: =?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Subject: Re: [PHP-DEV] About restricting the recursive implicit calls
From: bobwei9@hotmail.com (Bob Weinand)

Am 25.2.2013 um 17:45 schrieb Johannes Schl=FCter =
<johannes@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.
>=20
> For one the stack frames aren't always the same size on all nesting
> levels, depending on what's exactly happening.
>=20
> 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
>=20
> 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.=20
>=20
> 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