Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
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>
In-Reply-To: <BY2PR0201MB17840119CEB9BC06307ED2CEBFE20@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 01 Sep 2016 16:40:15 +0000
Message-ID: <CADVQu1SSOjwTx7A3-BFZ-sLPi=tEpcJPx6Fe6-4WpFyRXfHe4w@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.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>
Content-Type: multipart/alternative; boundary=94eb2c123712f8b4f0053b74de7f
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
From: dave@mudsite.com (David Walker)

--94eb2c123712f8b4f0053b74de7f
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 1, 2016 at 1:03 AM Dmitry Stogov <dmitry@zend.com> wrote:

> Hi David,
>
> I would propose to cancel voting and restart it when the good
> implementation is found.
>
> Otherwise, people may rise their hands for something that can't be
> implemented in good enough way.
>
> Thanks. Dmitry.
>

Hi Dmitry (et.al),

I ended up addressing the problem you raised where simply looking at the
next 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
good implementation?  The attempt to limit the quantity of raised warnings,
and raising once for a null, does need to be aware if the return of our op,
is 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 within zend_vm.  I'm wondering if a more acceptable implementation
would be to 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
brought 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 honestly set.  The idea that array-access on null just be ignored.  I'm
not sure 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 safely be ignored.

Thanks
--
Dave

--94eb2c123712f8b4f0053b74de7f--