Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.213.43 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>
 <CADVQu1SSOjwTx7A3-BFZ-sLPi=tEpcJPx6Fe6-4WpFyRXfHe4w@mail.gmail.com>
 <BY2PR0201MB17844B23AC958588BF147676BFE50@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CADVQu1SjX3OMg66+SU4YoSUOE5x5cP83inJhdFCU53bWnuJD-Q@mail.gmail.com> <7eb5f710-b34d-743a-3563-4e74e5995d41@gmx.de>
In-Reply-To: <7eb5f710-b34d-743a-3563-4e74e5995d41@gmx.de>
Date: Fri, 02 Sep 2016 15:42:24 +0000
Message-ID: <CADVQu1T-t2f_ARXFq=a-MHzjj8KTr_QyseHmbHojG3BmSiEiTg@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>, Dmitry Stogov <dmitry@zend.com>, 
	Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>, Nikita Popov <nikic@php.net>
Content-Type: multipart/alternative; boundary=001a114288fcedb509053b882d76
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
From: dave@mudsite.com (David Walker)

--001a114288fcedb509053b882d76
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 2, 2016 at 9:28 AM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 02.09.2016 at 16:57, David Walker wrote:
>
> > Poking around, I'm must not be understanding how TICK opcodes would
> > negatively impact the lookahead.  It may be my newness, but the way I'm
> > reading the compilation of ZEND_AST_DIM, would not be suspect to random
> > TICK opcodes from impacting the lookahead.  I see that for a single
> > ZEND_AST_DIM, compilation will recuse emitting all the FETCH_DIM_R
> opcodes
> > for it in succession.  Whereafter, a subsequent call to
> zend_compile_stmt()
> > will emit the TICK if it was declared.  It could also be that I'm unsure
> > what a test example would be that could inject the TICK into the middle,
> of
> > the DIM compilation.
> >
> > The same applies to the BEGIN/END silence, as they will be wrapped around
> > the entire compilation of the DIM opcodes.  [1] has an example using both
> > ticks and silencing, which seems to work as intended emitting a single
> > warning (for the un-silenced access)
> >
> > I'm not exactly sure what you mean by debugging-opcodes here though,
> > however, unless someone is hooking into the compilation and compiling
> DIM's
> > in a different way, I don't see the inherent problems with the lookahead.
> >
> > I was thinking about the use of an exception, however, I think that'd be
> a
> > pretty significant shift.  It would also be very odd that this case would
> > be the exception throwing one, whereas accessing via reference wouldn't,
> or
> > any of the undefined indexes wouldn't.  It would also impact most user
> code
> > out there by needing to wrap variable array access in a try{}catch, which
> > would be imposing a pretty large change to php 8.0.  That's why I didn't
> > really think shifting to an exception would be appropriate here.
> >
> > Thanks
> > --
> > Dave
> >
> > [1] - https://gist.github.com/bp1222/18d80e8ec962eba1ba75c99124191a0a
>
> I don't understand why we're even trying to hack this, let alone
> considering to throw an exception.  Why don't we handle array
> dereferencing just like property access, which also might throw multiple
> notices, see <https://3v4l.org/v49i7>.  If this is considered too much
> of a BC break for 7.2, we still could postpone that change to 8.0.
>
> --
> Christoph M. Becker
>

Christoph,

I somehow remember this being raised at some point during this RFC,
although I can't seem to find where now.

I'd offer that it shouldn't be doing that.  I would be of the opinion that
when an error condition appears, it shouldn't cascade the errors onwards.
As such, your example there, I'd desire a single notice raised.
FETCH_OBJ_R could benefit in the same way I'm attempting the lookahead to
FETCH_DIM_R.  Although, I'd be open to raising errors if that's what's
preferable.

Thanks
--
Dave

--001a114288fcedb509053b882d76--