Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45358
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 204.13.248.71 cause and error)
Message-ID: <4A9304FC.2000906@sci.fi>
Date: Tue, 25 Aug 2009 00:24:12 +0300
Reply-To: jani.taskinen@iki.fi
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Ilia Alshanetsky <ilia@prohost.org>, 
 'PHP Internals' <internals@lists.php.net>
References: <4A92D936.2010107@zend.com> <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org> <4A92DC60.2050606@zend.com> <BE47C3D9-A9FA-45CD-A004-79C8479AFDD3@prohost.org> <4A92EA60.6020605@zend.com> <D3312479-4C3C-4F95-8503-FA0633FF835E@prohost.org> <4A92F13B.9000204@zend.com> <CCC293B8-52C8-4473-8027-6F7B32DC0C3F@prohost.org> <4A92FFA8.1060401@zend.com>
In-Reply-To: <4A92FFA8.1060401@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] error masks
From: jani.taskinen@sci.fi (Jani Taskinen)

Quite boring to read this thread where two persons argue about something 
abstract. Stas, can you give a real life example where your patch is necessary..?

--Jani

Stanislav Malyshev wrote:
> Hi!
> 
>> Unless your code is "ridden" or if you prefer "filled" with @ and/or 
>> errors the speed improvement would be next to impossible to measure 
>> since you'd be literally saving microseconds. You'd need to have a 
> 
> Microsecond here, microsecond there - this stuff adds up. And 2-3 
> mallocs of substantial size (IIRC some messages are long enough so 
> emalloc caches do not apply) plus whole printf ordeal - even twice in 
> some cases - are not that small change, especially if it could happen 
> repeatedly. Of course it alone won't make you 50% speedup, but even 0.5% 
>  here and 0.5% there add up.
> BTW, if you benchmark only this thing (yes, I know, it's not realistic 
> :) the difference is very, very measurable - error reporting slows down 
> operation with ignored error 3-4 times. I think if I proposed an 
> improvement that would speed up certain set of opcodes 3 times that'd be 
> worth having, not?
> 
>> to make a reliably measurable difference. More over, if the user 
>> defines an error handler, which many applications, frameworks, etc... 
>> do then your improvement is next to invisible in between the overhead 
>> of executing PHP code to process the error.
> 
> The thing is you would be in control of which errors too feed to the 
> error handler and which not to. That's exactly the point - giving you 
> the tools to control it. Including tools to deal with "noisy" code the 
> way you like - which may be your way, my way or any way in between. If 
> you don't care - default changes nothing, but if you do, you have the 
> means to make it run faster.
> 
>> Vast majority of E_NOTICEs are not fixed not because people don't want 
> 
> You are still focused on one particular case of E_NOTICE. It's not 
> (only) what's it about, it's bigger.
> 
>> set to ignore those errors. And E_NOTICES btw often could've let 
>> people know about security faults before they were abused, such as 
>> uninitialized variables and array keys that could be injected via 
>> register_globals, extract() function, etc...
> 
> Yes, yes - if only they were actually *seen* by anybody. The case we 
> discuss here is when they *are not* seen anyway. So I don't see how your 
> argument applies. Your argument is about entirely different thing which 
> I do not argue with you about - that some warning should not be 
> disabled/hidden. I agree with you. But some OTHER warnings should be, 
> and that's the case I want to fix.
> 
>> Stas, my biggest issue is that you are making this configurable value 
>> that makes this open to abuse, rather then using 0 as default and 
>> matching the error message creation to error reporting settings.
> 
> It can be done too, but not having other configuration will disable some 
> scenarios when you don't want the error to go through usual reporting 
> mechanisms but want debugger/monitoring system still see it. I 
> understand that if we designed error_reporting from scratch maybe we'd 
> just say "one switch for everybody", but since we already have people 
> that are used to having current system, I made it as flexible as 
> possible. If people around here think it's too flexible I could just 
> make it on/off (i.e. same as -1/0 with current patch), it's trivial. I 
> just wanted to start with max flexibility.