Ferenc Kovacs wrote:
> On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker <cmbecke...@gmx.de> wrote:
>
>> Lester Caine wrote:
>>
>>> Yes it is only a number, but a lot more problematic changes WERE pushed
>>> through across those three versions which would have been much safer
>>> handled by removing e_strict from PHP5.4 rather than trying to live with
>>> both versions of PHP.
>>
>> I don't see a problem with regard to E_STRICT. If your code is not yet
>> strict compliant, simply turn it off for error_reporting:
>>
>> error_reporting = E_ALL & ~E_STRICT
>>
>> --
>> Christoph M. Becker
>
> for the record, see https://bugs.php.net/bug.php?id=65322 and the issued
> linked from that.
> turned out that we had a bug, which prevented the autoload calls inside an
> error handler call when the original error was a compile time one.
> we have some compile time strict errors about abstract classes which could
> have triggered hard-to-debug fatal errors for people(with custom error
> handlers which depend on dynamic auto loading) when we made E_STRICT part
> of E_ALL in 5.4.
Thanks for pointing this out -- I have not been aware of the issue. Of
course, having had this bug for such a long time is unfortunate, but it
seems to me a viable userland workaround for not yet "strict" code to
support affected PHP versions would be to pass an appropriate
$error_types argument to the set_error_handler call, e.g.
set_error_handler('my_error_handler', E_ALL & ~E_STRICT);
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
