Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74772 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71053 invoked from network); 6 Jun 2014 07:07:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jun 2014 07:07:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.187.115 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.187.115 smtp115.iad3a.emailsrvr.com Linux 2.6 Received: from [173.203.187.115] ([173.203.187.115:56979] helo=smtp115.iad3a.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/11-63196-79861935 for ; Fri, 06 Jun 2014 03:07:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BDCF340221; Fri, 6 Jun 2014 03:07:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 4663340229; Fri, 6 Jun 2014 03:07:01 -0400 (EDT) Message-ID: <53916894.4010001@sugarcrm.com> Date: Fri, 06 Jun 2014 00:07:00 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ferenc Kovacs CC: PHP Developers Mailing List References: <1361810738.2376.74.camel@guybrush> <512BA931.7010909@sugarcrm.com> <512BB284.4060900@sugarcrm.com> <1361826106.2376.78.camel@guybrush> <512E6732.6010601@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] About restricting the recursive implicit calls From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > 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. The problem here is not even that we break some app, but that stack depths and stack requirements are very different in different OSes, situations, etc. and that means the spaces which may break the app and the spaces where it still crashes may intersect, so it is not at all guaranteed that there's a predictable value for which the app always works and the stack is still safe. > 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? I don't know a way to check for potential stack depletion that would work in a portable way. Different calls may consume different amounts of stack space, so it's kind of hard to predict it in advance. Once it happened, I don't think you can gracefully bail from it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227