Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62788
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.185 cause and error)
Message-ID: <5045F939.6010806@lsces.co.uk>
Date: Tue, 04 Sep 2012 13:51:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <AANLkTimWuPXCs-HT6RgQYmH7UKcOYXkeTiMEnBwBXxnt@mail.gmail.com> <CAH-PCH4YdBr7WfQ2PR0_Fr_C=TfBsSGsbX3G-jonUqyfLrCcZQ@mail.gmail.com> <5040DC47.8000305@ajf.me> <CAH-PCH5TM2ag-5xm3Rk7Ef6LnpEst1UqRoc_f_Uwp_aLe418dA@mail.gmail.com> <5040F4D9.80206@sugarcrm.com> <CAEZPtU6X9gLRALzA+KGKNoF5c7ey-xgJ=0NhjF2qVfD9YJqN+Q@mail.gmail.com> <5042946A.80204@sugarcrm.com> <op.wjzdwn08idpuyk@damnation.nl.lo.geleia.net> <5042A7D6.7050001@lerdorf.com> <op.wjzgbuh1idpuyk@damnation.nl.lo.geleia.net> <alpine.DEB.2.02.1209031214250.25835@whisky.home.derickrethans.nl> <a565e97fdd574cebf2baca1c54c425a2@nebm.ist.utl.pt> <50452713.3020307@sugarcrm.com> <b6bf26cb6b4d2392d5fd13237669a19d@nebm.ist.utl.pt> <5045CAA3.6000409@lsces.co.uk> <CAEZPtU77K_wdRErqEQ1ZXj1_sWY2N_UcNkZsL5_h3UfjDmQK1Q@mail.gmail.com> <5045E044.9080809@lsces.co.uk> <CAL+t6cHD05znYaq7iPNwFNem=zma0-htbPG-Fc3550U-s5jcRA@mail.gmail.com>
In-Reply-To: <CAL+t6cHD05znYaq7iPNwFNem=zma0-htbPG-Fc3550U-s5jcRA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php
 core?
From: lester@lsces.co.uk (Lester Caine)

Sherif Ramadan wrote:
> On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine <lester@lsces.co.uk> wrote:
>> Pierre Joye wrote:
>>>>
>>>> How many of the major PHP user projects ARE currently strict compliant?
>>>> And
>>>>> how many are still requiring E_STRICT switched off in PHP5.4?
>>>
>>> This is a development and very useful. PHP does not enforce this mode.
>>> And like any other errors, it only ends in your logs.
>>>
>>> But this has been told to you a good dozen of times in the past, and
>>> it is really getting ridiculous to have to explain that over and over.
>>
>>
>> And the point of YOUR comments?
>> With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash
>> if they have not been 'converted'!
>>
>
> E_STRICT can't crash you program. It's just like an E_WARNING or
> E_NTOICE level error. It's non-fatal. It does not inhibit the
> execution of code.

??? OH YES IT DOES !!!
MANY times I get a a few lines of text on a white screen ...
Switch off E_STRICT and everything works fine ... as it was on PHP5.2

>> The QUESTION is a perfectly valid one ... especially when I've just hit yet
>> another current project that we have to make sure to disable E_STRICT when
>> they get transferred to a PHP5.4 machine! I have no doubt a lot more will
>> also be affected and so knowing the right answers is important. As perhaps
>> is understanding the reason some projects are not converting code?
>>
>
> What exactly is the question that you're posing to PHP Internals? An
> audit of how much code doesn't follow strict standards? Probably a
> lot. I've seen plenty of it in production myself and among them even
> the most popular PHP frameworks. Having tested Joomla on PHP 5.4
> before a switch to production I recall seeing an actual drop in
> performance due to the sheer number of E_DEPRECATED and/or E_STRICT
> errors that the code produced.
That is one which was white screening for me, and all I was trying to do was a 
favour for some one. A quick hack of the config file and we were working again, 
but certainly some modules in Joomla are not save when used with E_STRICT set!

> However, none of that prevented the code from running (or "crashing"
> as you say). All you have to do is change the error_reporting
> directive if you chose to ignore those errors for the time being. You
> simply don't have display_errors on in production anyway so the worst
> possible outcome here is that you end up with an error log stuffed
> with those errors. Nothing critical here.
>
> This is not even a minor concern for most code basis that exhibit this
> problem to a great degree because the majority of them aren't willing
> to upgrade to 5.4 or have realized the problem by now and are fixing
> their code.

The 'concern' is that ISP's are following the recommendations, and using the 
default production setup, so E_STRICT is on - PLEASE LEAVE IT OFF should be the 
standard!

>> While the preference on PHP5.4 may be to force people to comply, the reality
>> is that this is a switch which it's more likely needs switching off in
>> production simply because user land has no idea how to handle the problems
>> yet. And I'll keep banging on until what is distributed from the php.net
>> site actually works on a current default install ...
>>
>
> The userland problem is a trivial issue. All they have to do is turn
> display_errors off in production as is recommended and is the default
> anyway. There is nothing major here to hold you back other than
> yourself.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk