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<mailto: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<http://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
