Dmitry,
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
On Fri, Sep 2, 2016 at 12:19 AM Dmitry Stogov <dmi...@zend.com> wrote:
> Looking forward won't always work out of the box.
>
> Take into account possible TICK opcodes, BEGIN/END silence, debugging
> opcodes.
>
> 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 <d...@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 <dmi...@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
>
