Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74770
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7BHyF9fenTR5Tqih_0=xY4O3_y2h3GmfPh4JGhgEXWtQ@mail.gmail.com>
References: <BLU0-SMTP17590EBA81C73B80FBD2DC4E2F30@phx.gbl>
	<1361810738.2376.74.camel@guybrush>
	<BLU0-SMTP192F5092E7FAF349E58EF14E2F30@phx.gbl>
	<512BA931.7010909@sugarcrm.com>
	<BLU0-SMTP440413F63B6853F3921B28AE2F30@phx.gbl>
	<512BB284.4060900@sugarcrm.com>
	<BB36A9AE-15FE-48F4-BC6E-536DD6B9ECD7@hotmail.com>
	<BLU0-SMTP84AA375FFBF9F72D47CB87E2F30@phx.gbl>
	<1361826106.2376.78.camel@guybrush>
	<BLU0-SMTP17598AB345B5FB936E836B2E2F30@phx.gbl>
	<BLU0-SMTP592778DB54F0E3C384B3FEE2FD0@phx.gbl>
	<512E6732.6010601@sugarcrm.com>
	<CAH-PCH7BHyF9fenTR5Tqih_0=xY4O3_y2h3GmfPh4JGhgEXWtQ@mail.gmail.com>
Date: Fri, 6 Jun 2014 08:25:00 +0200
Message-ID: <CAH-PCH7nx2=kyA4O+B5-fMOAgrNjDNyBFiiWNPisk-ztZ6+PxQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>, Dmitry Stogov <dmitry@php.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c11d12d3ae8e04fb24ebd6
Subject: Re: [PHP-DEV] About restricting the recursive implicit calls
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c11d12d3ae8e04fb24ebd6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 27, 2013 at 10:15 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
>
> On Wed, Feb 27, 2013 at 9:06 PM, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
>
>> Hi!
>>
>> > May someone merge this PR (#290) as there are no arguments against it?
>>
>> I just outlined arguments against it in my last emails. If your email is
>> not working properly and you miss some emails please check the list
>> archives.
>>
>> > Or do I have to wait a little bit? (How long?)
>>
>> In my personal opinion, indefinitely long, since I think it is not a
>> good idea at all to have it in the core, and the same functionality
>> already exists in xdebug.
>>
>>
> and in suhosin.
> I think that it is a pretty handy feature, both from the security
> pov(hitting a fatal error is better than php crashing, killing the worker=
s,
> resetting random seed, etc.) and can help with debugging the problem(as y=
ou
> will lose the non flushed output buffer on the crash).
> so if we could find an implementation which addresses your issues(no majo=
r
> perf cost, sane defaults, no edge cases left out, etc.) then I can't see
> why we shouldn't add it.
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

sorry for resurecting the old thread,
if we are concerned about the perf cost of counting and checking the
recursion, and that the default value would break some application, maybe
we could introduce this as an optional feature: the ini setting is 0 by
default, which will disable even the checks for recursion, so people have
to opt-in to use it and it's their burden to configure it properly.
I know that this would still allow distros and hosters to misuse it, and
probably some apps will start checking for this setting to (hopefully only)
warn about the setting being too low, or even picking a different strategy
when the setting is too low or simply increasing the limit at runtime.
maybe we can do something in the next major version which would allow us to
gracefully bail from these kind of errors without imposing arbitrary limits=
?

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c11d12d3ae8e04fb24ebd6--