Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <545B589A.4010606@gmx.de>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com>
	<CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com>
	<3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me>
	<CAEZPtU5bdrgX3yfNZhPsWqrU6d5fw=vX78-iW=gx1jUJoeF8YA@mail.gmail.com>
	<04723EAD-4C8E-41C2-BE81-4989882A0C69@ajf.me>
	<545B26BB.9020406@lsces.co.uk>
	<545B589A.4010606@gmx.de>
Date: Thu, 6 Nov 2014 13:10:26 +0100
Message-ID: <CAH-PCH56mVMk0S2JzVOM9y7Jbu2mdQEss6E+NDBZne_YSTFWnA@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: Lester Caine <lester@lsces.co.uk>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d6c00e8472b05072f9406
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a113d6c00e8472b05072f9406
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker <cmbecker69@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 wit=
h
> > 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 =3D E_ALL & ~E_STRICT
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> for the record, see https://bugs.php.net/bug.php?id=3D65322 and the issue=
d
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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113d6c00e8472b05072f9406--