Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender)
Message-ID: <4A932ABA.4090006@zend.com>
Date: Mon, 24 Aug 2009 17:05:14 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Greg Beaver <greg@chiaraquartet.net>, 
 'PHP Internals' <internals@lists.php.net>
References: <4A92D936.2010107@zend.com> <4A931A1C.804@chiaraquartet.net> <3EB779A6-0584-4368-B290-8026DEB960D3@pooteeweet.org>
In-Reply-To: <3EB779A6-0584-4368-B290-8026DEB960D3@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [patch] error masks
From: stas@zend.com (Stanislav Malyshev)

Hi!

> Stats "@fopen()" example is perfect here, so lets say we do add this 
> feature and people simply turn of error's entirely so that they can 
> instead write "fopen()", they feel all good about themselves, since they 
> handle the error locally and get a magical speed boost (noticeable or 
> not) .. all the while they are ignoring all sorts of E_NOTICES that 
> would indicate them that they have some serious security issues.

Actually, my point was that even if you write that code "right", only 
thing you achieve is slow code. It would still not be robust, unless you 
create if() and custom error handler for every imaginable error, it's 
still not more secure (since all the security works on stream level and 
applies to both is_readable and fopen anyway), summarily it's not better 
in any way but by giving you this nice feeling you "invested into nicer 
code". Which is totally imaginary since your code has virtually no 
difference from the old one except being slower. And all this because of 
@-phobia :)

> Again, I am all for being able to totally ignore E_STRICT/E_DEPRECATED 
> in production .. but there is a time for fixing E_NOTICES .. and that 
> time is always!

If you think it is (and note it's not the law of the universe - I could 
think about dozens of use cases where E_NOTICE is useless and you *know* 
you don't want it) - go ahead and set you error mask to include 
E_NOTICE, there's nothing easier. It's not like anybody is advocating 
there should be only one error mask. On the contrary, I advocate 
flexible approach where everybody can choose the mask that fits his 
particular use case.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com