Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95577
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: David Walker <dave@mudsite.com>, Dmitry Stogov <dmitry@zend.com>,
 Marco Pivetta <ocramius@gmail.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>
 <BY2PR0201MB17844B23AC958588BF147676BFE50@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CADVQu1SjX3OMg66+SU4YoSUOE5x5cP83inJhdFCU53bWnuJD-Q@mail.gmail.com>
Cc: PHP Internals List <internals@lists.php.net>, Nikita Popov <nikic@php.net>
Message-ID: <7eb5f710-b34d-743a-3563-4e74e5995d41@gmx.de>
Date: Fri, 2 Sep 2016 17:28:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CADVQu1SjX3OMg66+SU4YoSUOE5x5cP83inJhdFCU53bWnuJD-Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
From: cmbecker69@gmx.de ("Christoph M. Becker")

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