Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45402 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29577 invoked from network); 25 Aug 2009 18:16:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2009 18:16:50 -0000 Authentication-Results: pb1.pair.com header.from=danielc@analysisandsolutions.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=danielc@analysisandsolutions.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain analysisandsolutions.com from 166.84.1.73 cause and error) X-PHP-List-Original-Sender: danielc@analysisandsolutions.com X-Host-Fingerprint: 166.84.1.73 mail2.panix.com Received: from [166.84.1.73] ([166.84.1.73:60078] helo=mail2.panix.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AC/95-22580-09A249A4 for ; Tue, 25 Aug 2009 14:16:49 -0400 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 46CA038E4F for ; Tue, 25 Aug 2009 14:16:45 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 14662) id 31F0F24207; Tue, 25 Aug 2009 14:16:45 -0400 (EDT) Date: Tue, 25 Aug 2009 14:16:45 -0400 To: PHP Internals List Message-ID: <20090825181644.GA17485@panix.com> References: <4A92D936.2010107@zend.com> <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org> <4A92DC60.2050606@zend.com> <4A92EA60.6020605@zend.com> <4A92F13B.9000204@zend.com> <20090825030925.GA21165@panix.com> <4A93880A.9080408@zend.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A93880A.9080408@zend.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [PHP-DEV] [patch] error masks From: danielc@analysisandsolutions.com (Daniel Convissor) Hey Stas: On Mon, Aug 24, 2009 at 11:43:22PM -0700, Stanislav Malyshev wrote: > > That's true. So, if you use code that uses $php_errormsg, of course you > can not use this optimization and should not enable it (at least for > error types and code parts that you use $php_errormsg with). Exactly. Totally killing E_STRICT on it's own seems like the biggest win (in the right circumstances). My main point is that we need to think this thing through carefully and document it well. > Also, if you use @ to stop warning output to the browser you should read > the manual about display_errors and part of the security guidelines when > it says never enable display_errors in production ;) Of course. But folks don't want those same messages showing up in the error log, either. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409