Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55629 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47262 invoked from network); 26 Sep 2011 17:08:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Sep 2011 17:08:43 -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 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:38745] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/85-02759-991B08E4 for ; Mon, 26 Sep 2011 13:08:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id AE7BA30048E; Mon, 26 Sep 2011 13:08:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 33AAB3003F9; Mon, 26 Sep 2011 13:08:38 -0400 (EDT) Message-ID: <4E80B195.7030400@sugarcrm.com> Date: Mon, 26 Sep 2011 10:08:37 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Pierre Joye CC: PHP internals , Scott MacVicar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Merge fix for #54918 (r311748) to 5.4? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 9/26/11 1:42 AM, Pierre Joye wrote: > It may be good to merge > http://svn.php.net/viewvc?view=revision&revision=311748 to 5.4 too. > This commit is about issues similar to the one describe in #54918. > > Any reason not to do it before next beta/rc? I'm not sure I understand this patch completely. I understand that if one of the MINITs fails, this patch just continues. But we have tons of code that assumes all basic MINITs worked - we always use variables initialized in these MINITs without checking, etc. So does it really make sense to continue if one of basic MINITs fail? On regular module loading, MINIT failure is E_CORE_ERROR, why not here? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227