Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.178 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>
In-Reply-To: <e6544e5e-7c47-b7ee-4067-85897d0035b9@gmx.de>
Date: Wed, 31 Aug 2016 13:48:10 +0000
Message-ID: <CADVQu1Sf5r2xt9Vj+-OyT1gfGGROxXacwbXWd5x8mzTh-NMwfg@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=94eb2c18f38ab5886c053b5e59c7
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
From: dave@mudsite.com (David Walker)

--94eb2c18f38ab5886c053b5e59c7
Content-Type: text/plain; charset=UTF-8

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.
> >
>

--94eb2c18f38ab5886c053b5e59c7--