Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66209 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85461 invoked from network); 25 Feb 2013 18:27:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2013 18:27:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.107 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.107 blu0-omc2-s32.blu0.hotmail.com Windows 2000 SP4, XP SP1 Received: from [65.55.111.107] ([65.55.111.107:43067] helo=blu0-omc2-s32.blu0.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2D/53-10787-D1DAB215 for ; Mon, 25 Feb 2013 13:27:42 -0500 Received: from BLU0-SMTP403 ([65.55.111.72]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 10:27:39 -0800 X-EIP: [O3N3/dnC0hdc4wmFlErPhm+MOp5IWeWD] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Received: from bob-weinands-imac.fritz.box ([78.141.134.76]) by BLU0-SMTP403.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 10:27:37 -0800 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: <512BA88C.4050704@sugarcrm.com> Date: Mon, 25 Feb 2013 19:27:34 +0100 CC: PHP Mailing List Developers Content-Transfer-Encoding: quoted-printable References: <512BA88C.4050704@sugarcrm.com> To: Stas Malyshev X-Mailer: Apple Mail (2.1499) X-OriginalArrivalTime: 25 Feb 2013 18:27:37.0889 (UTC) FILETIME=[C9E15910:01CE1385] Subject: Re: [PHP-DEV] About restricting the recursive implicit calls From: bobwei9@hotmail.com (Bob Weinand) Am 25.2.2013 um 19:08 schrieb Stas Malyshev : > Hi! >=20 >>=20 >> p.s.: There is no reason why not to fix this in this way, I think, >=20 > There actually is. First, any option modifying engine behavior creates = a > compatibility problem, since now the code that needs to work with it = has > to check and be tested for yet another variable. Second, why does it > concentrate on magics? You can get stack overflow with any functions. >=20 > --=20 > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 It doesn't break if the limit is not set too low. It is like I now is, = only without the segmentation faults. No, normal functions don't crash as - not 100% sure if I'm right - the = Zend Engine erealloc's (under control of the MM (and the memory limit)) the previous = function context and then returns; after the execution of the function the stack = is restored: a stack is only emulated and cannot cause crashes (the real c stack = doesn't grow). I concentrate only on implicit function calls as they are the only = problem. Bob