Re: About restricting the recursive implicit calls
| From: | Ferenc Kovacs | Date: | Fri, 06 Jun 2014 06:25:00 +0000 |
| Subject: | Re: About restricting the recursive implicit calls | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74770@lists.php.net to get a copy of this message | ||
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 workers,
> resetting random seed, etc.) and can help with debugging the problem(as you
> will lose the non flushed output buffer on the crash).
> so if we could find an implementation which addresses your issues(no major
> perf cost, sane defaults, no edge cases left out, etc.) then I can't see
> why we shouldn't add it.
>
> --
> Ferenc Kovács
> @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?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu