Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95519
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.174 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>
In-Reply-To: <CADVQu1Sf5r2xt9Vj+-OyT1gfGGROxXacwbXWd5x8mzTh-NMwfg@mail.gmail.com>
Date: Wed, 31 Aug 2016 13:49:59 +0000
Message-ID: <CADVQu1ToLqo05Pwq-zVQLv5fYxtMa4oL6rVVOyMqXbUD=BQ6iQ@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=001a11430d0423fc4f053b5e608d
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
From: dave@mudsite.com (David Walker)

--001a11430d0423fc4f053b5e608d
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 31, 2016 at 7:48 AM David Walker <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>
> 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>
>> > 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>> 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.

--001a11430d0423fc4f053b5e608d--