Re: Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
| From: | Dmitry Stogov | Date: | Thu, 01 Sep 2016 07:03:42 +0000 |
| Subject: | Re: Re: [RFC][VOTE] E_WARNING on invalid container read-adccess | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95529@lists.php.net to get a copy of this message | ||
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.
________________________________
From: David Walker <dave@mudsite.com>
Sent: Thursday, September 1, 2016 3:05:44 AM
To: Christoph M. Becker; Dmitry Stogov; Marco Pivetta
Cc: PHP Internals List; Nikita Popov
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
On Wed, Aug 31, 2016 at 7:49 AM David Walker <dave@mudsite.com<mailto:dave@mudsite.com>> wrote:
On Wed, Aug 31, 2016 at 7:48 AM David Walker <dave@mudsite.com<mailto:dave@mudsite.com>> wrote:
I too get Dmitry's result. As the left hand side is an error-zval, and the right hand is null,
it explodes. Yes, the hackish way I try and resolve things was to check opcodes around the current
one, which I should have thought in the case of addition wouldn't have been valid. The entire
goal of the RFC was to prevent warning for obvious results (as it specifies on long string of
accesses). One, thought about and ignored by me, aspect to the RFC was the concept of a null
entity. Wherein any array access on null would result with null. I believe this could result in
resolving many of the headaches I'm attempting to resolve by managing a null-return from array
access as a literal null, or unknown cast to null.
On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>> wrote:
On 31.08.2016 at 12:10, Dmitry Stogov wrote:
> no. if you would try the proposed PR with this code, you would see:
>
>
> Fatal error: Uncaught Error: Unsupported operand types
I get the following behavior against PR #1269:
$ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
var_dump(\$a[0][0] + \$c[0]);"
Notice: Trying to get index of a non-array in Command line code on line 1
Notice: Trying to get index of a non-array in Command line code on line 1
int(0)
Cheers!
> ________________________________
> From: Marco Pivetta
> <ocramius@gmail.com<mailto:ocramius@gmail.com>>
> Sent: Wednesday, August 31, 2016 10:10:23 AM
> To: Dmitry Stogov
> Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker
> Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
>
>
> Hi Dmitry,
>
> On 31 Aug 2016 8:37 a.m., "Dmitry Stogov"
> <dmitry@zend.com<mailto:dmitry@zend.com><mailto:dmitry@zend.com<mailto:dmitry@zend.com>>>
> wrote:
>>
>> I vote NO, because the implementation introduces more problems than intents to fix.
>>
>> For example the following code starts to throw exception:
>>
>>
>> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>
>
> Isn't that the point of this RFC?
> I would expect this code to only ever work by accident.
>
Apologies in advance for the toppost. Gmail is the bane of my existence in regards to mailing
lists.
Hi all,
As of now, the scheduled time the vote is to close, the RFC stands 19-4 (accepted). Given this is
my first solo RFC, I'm not really sure protocol to go from here. Dmitry does raise that the
implementation I put forward maybe a bit hackish compared to what someone much more knowledgeable
could implement. So I'm not certain if the RFC should be deemed accepted, or, fall into the
howto section 7(3) and go back to discussion (if it is considered a serious issue).
Direction appreciated.
--
Dave