Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95551
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.33.130 as permitted sender)
To: David Walker <dave@mudsite.com>, "Christoph M. Becker"
	<cmbecker69@gmx.de>, Marco Pivetta <ocramius@gmail.com>
CC: PHP Internals List <internals@lists.php.net>, Nikita Popov <nikic@php.net>
Thread-Topic: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
Thread-Index: AQHR/sbmD9xxW9A3CEyHAOpTP2AfSKBiom/BgAANfoCAADEn/YAACJCAgAA1bQCAAACBgIAArAoAgABzN8aAAKKngIAA4uKR
Date: Fri, 2 Sep 2016 06:19:22 +0000
Message-ID: <BY2PR0201MB17844B23AC958588BF147676BFE50@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CADVQu1QXag1h_hnOcFYejMbsDrV+4ZQCwKNJmb4EedBB6S33Ww@mail.gmail.com>
 <1e6cac8a-e1af-c9e7-a900-a2efda0771dd@gmx.de>
 <BY2PR0201MB17843B394401BED590828E3ABFE30@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CADyq6s+2VdTkeBM8gM_pmH=M=jJd3aYzKU5WKu8iGjiopNbPPA@mail.gmail.com>
 <BY2PR0201MB1784EC2F73A3384B39013287BFE30@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <e6544e5e-7c47-b7ee-4067-85897d0035b9@gmx.de>
 <CADVQu1Sf5r2xt9Vj+-OyT1gfGGROxXacwbXWd5x8mzTh-NMwfg@mail.gmail.com>
 <CADVQu1ToLqo05Pwq-zVQLv5fYxtMa4oL6rVVOyMqXbUD=BQ6iQ@mail.gmail.com>
 <CADVQu1SMuR1eXBWdQDVYJPCVDVzC4fz1biNv_EFOjWEuf6EwRg@mail.gmail.com>
 <BY2PR0201MB17840119CEB9BC06307ED2CEBFE20@BY2PR0201MB1784.namprd02.prod.outlook.com>,<CADVQu1SSOjwTx7A3-BFZ-sLPi=tEpcJPx6Fe6-4WpFyRXfHe4w@mail.gmail.com>
In-Reply-To: <CADVQu1SSOjwTx7A3-BFZ-sLPi=tEpcJPx6Fe6-4WpFyRXfHe4w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB17844B23AC958588BF147676BFE50BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2016 06:19:22.7441
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB17844B23AC958588BF147676BFE50BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Looking forward won't always work out of the box.

Take into account possible TICK opcodes, BEGIN/END silence, debugging opcod=
es.

It's probably easier to throw exception, instead of recovery, but this is a=
 BC break, and might be done only in 8.0.


Thanks. Dmitry.

________________________________
From: David Walker <dave@mudsite.com>
Sent: Thursday, September 1, 2016 7:40:15 PM
To: Dmitry Stogov; Christoph M. Becker; Marco Pivetta
Cc: PHP Internals List; Nikita Popov
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-=
adccess

On Thu, Sep 1, 2016 at 1:03 AM Dmitry Stogov <dmitry@zend.com<mailto:dmitry=
@zend.com>> wrote:

Hi David,

I would propose to cancel voting and restart it when the good implementatio=
n is found.

Otherwise, people may rise their hands for something that can't be implemen=
ted in good enough way.

Thanks. Dmitry.

Hi Dmitry (et.al<http://et.al>),

I ended up addressing the problem you raised where simply looking at the ne=
xt opcode type wasn't verbose enough, and had the thrown exception.

So I'm wondering the reasons why looking ahead wouldn't be considered a goo=
d implementation?  The attempt to limit the quantity of raised warnings, an=
d raising once for a null, does need to be aware if the return of our op, i=
s being used again in the next op.  I do notice that in zend_execute there'=
s no other examples of looking forward an opline, but that it does exist wi=
thin zend_vm.  I'm wondering if a more acceptable implementation would be t=
o move the logic of looking-forward and checking if the next fetch-dim-r to=
 the opcode-handler.

Or, if your concern is more with the looking-forward in general.  It was br=
ought up a while back (and on the PR) of the problems associated with being=
 able to handle a null-return from error, as compared to a null that is hon=
estly set.  The idea that array-access on null just be ignored.  I'm not su=
re if this would be seen as the more acceptable implementation which would =
remove the need to look-ahead in oplines, as a NULL (error) result would sa=
fely be ignored.

Thanks
--
Dave

--_000_BY2PR0201MB17844B23AC958588BF147676BFE50BY2PR0201MB1784_--