Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 74.125.92.25 cause and error)
Cc: Stanislav Malyshev <stas@zend.com>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <4B0E7BED-C2AE-4BE5-B6CA-00B810168961@prohost.org>
To: Greg Beaver <greg@chiaraquartet.net>
In-Reply-To: <4A9346CA.3070608@chiaraquartet.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 24 Aug 2009 22:48:14 -0400
References: <4A92D936.2010107@zend.com> <4A931A1C.804@chiaraquartet.net> <39F20BFC-DAA0-4403-A52E-62CE5F4CF0FE@prohost.org> <4A9346CA.3070608@chiaraquartet.net>
Subject: Re: [PHP-DEV] Re: [patch] error masks
From: ilia@prohost.org (Ilia Alshanetsky)

Greg,

If you enable error log you would be able to identify errors, even in  
legacy code fairly quickly and address them as needed. The speed  
increase, by Stas' own admission is very minimal here, I would wager  
that it would be small enough that on a application generating 2-3  
E_STRICTs per request you would not even be able to measure it. While  
saving memory and eliminating what effectively is a NOOP is a good  
idea, making it a configurable, user settable option, will simply lead  
to much abuse.

If the ultimate goal here is to save memory, why not simply set the  
mask to 0, which if understand Stas' original message correctly would  
equate its value to whatever the error reporting is set to.


On 24-Aug-09, at 10:04 PM, Greg Beaver wrote:

> Ilia Alshanetsky wrote:
>>
>> On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:
>>>
>>> 2) as long as the patch does not break any backwards compatibility
>>> (error logging still works as it always did independent of  
>>> error_mask,
>>> user error handlers still get the same stuff), why would we care?   
>>> There
>>> is a time and place for being academic about fixing things and it is
>>> called development, not production.
>>
>> You must not have any bugs in production environment, I am very  
>> envious.
>> :-)
>
> Ilia,
>
> I don't see how this kind of emotional hyperbole contributes  
> positively
> to the discussion.
>
> If I understand you right, you're arguing that people should never use
> code in production that emits errors.  That is certainly the goal.   
> It's
> also not always possible to do this when relying upon third-party code
> which may have been written for a pre-E_STRICT or a pre-E_DEPRECATED  
> php
> version.
>
> What I don't understand is why you think this:
>
> <?php
> error_reporting(E_WARNING|E_ERROR|E_NOTICE|E_USER_WARNING| 
> E_USER_ERROR|E_USER_NOTICE);
> class A
> {
> // emits an E_STRICT normally, and we waste cycles emitting an  
> E_STRICT
> that is never emitted
>    function A(){}
> }
> ?>
>
> is better than:
>
> <?php
> ini_set('error_mask',
> E_WARNING|E_ERROR|E_NOTICE|E_USER_WARNING|E_USER_ERROR|E_USER_NOTICE);
> class A
> {
> // just works (TM) as fast as it did in PHP 4
>    function A(){}
> }
> ?>
>
> IF (and a big if) no user error handler is in place, which should pass
> all possible errors into the error handler.
>
> If your fear is that third party people might do something  
> horrendous like:
>
> <?php
> ini_set('error_mask', 0);
> stupidfatalerror();
> ?>
>
> That's also easily solved by making it INI_SYSTEM.
>
> Greg