Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66215 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94442 invoked from network); 25 Feb 2013 18:50:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2013 18:50:49 -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.6.147 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.6.147 smtp147.ord.emailsrvr.com Linux 2.6 Received: from [173.203.6.147] ([173.203.6.147:35893] helo=smtp147.ord.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/55-10787-882BB215 for ; Mon, 25 Feb 2013 13:50:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 135EB2701CA; Mon, 25 Feb 2013 13:50:46 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.ord1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id B411527008E; Mon, 25 Feb 2013 13:50:45 -0500 (EST) Message-ID: <512BB284.4060900@sugarcrm.com> Date: Mon, 25 Feb 2013 10:50:44 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bob Weinand CC: PHP List Developers Mailing References: <1361810738.2376.74.camel@guybrush> <512BA931.7010909@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] About restricting the recursive implicit calls From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > You may use recursive functions (which are limited by the memory_limit), > but if you use recursive magics, it's a design error. This is not the purpose > of magics (, call_user_func(_array)?) and simply an abuse of the language. I think you are confusing magic functions with internal functions and functions being called from internal functions. These are different things. Looking at your patch, you are changing zend_call_function, which can be called in many situations, every time engine code calls any function which is not from a userspace context (i.e. PHP code). Limiting it to any arbitrary number can (and does) break code, that's why it wasn't done (it's not like it wasn't knows for years) and there are extensions - like xdebug - which do introduce such limits. In any case, 100 is way, way too low. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227