Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95529
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.37.96 as permitted sender)
To: David Walker <dave@mudsite.com>, "Christoph M. Becker"
	<cmbecker69@gmx.de>, Marco Pivetta <ocramius@gmail.com>
CC: PHP Internals List <internals@lists.php.net>, Nikita Popov <nikic@php.net>
Thread-Topic: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
Thread-Index: AQHR/sbmD9xxW9A3CEyHAOpTP2AfSKBiom/BgAANfoCAADEn/YAACJCAgAA1bQCAAACBgIAArAoAgABzN8Y=
Date: Thu, 1 Sep 2016 07:03:42 +0000
Message-ID: <BY2PR0201MB17840119CEB9BC06307ED2CEBFE20@BY2PR0201MB1784.namprd02.prod.outlook.com>
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>
 <CADVQu1ToLqo05Pwq-zVQLv5fYxtMa4oL6rVVOyMqXbUD=BQ6iQ@mail.gmail.com>,<CADVQu1SMuR1eXBWdQDVYJPCVDVzC4fz1biNv_EFOjWEuf6EwRg@mail.gmail.com>
In-Reply-To: <CADVQu1SMuR1eXBWdQDVYJPCVDVzC4fz1biNv_EFOjWEuf6EwRg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB17840119CEB9BC06307ED2CEBFE20BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2016 07:03:42.4790
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB17840119CEB9BC06307ED2CEBFE20BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi David,


I would propose to cancel voting and restart it when the good implementatio=
n is found.

Otherwise, people may rise their hands for something that can't be implemen=
ted 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 t=
hings was to check opcodes around the current one, which I should have thou=
ght in the case of addition wouldn't have been valid.  The entire goal of t=
he 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 R=
FC was the concept of a null entity.  Wherein any array access on null woul=
d result with null.  I believe this could result in resolving many of the h=
eadaches I'm attempting to resolve by managing a null-return from array acc=
ess as a literal null, or unknown cast to null.

On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de<mail=
to: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=3D-1 -r "\$a =3D [null]; \$c =3D 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 rea=
d-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 inte=
nts to fix.
>>
>> For example the following code starts to throw exception:
>>
>>
>> <?php $a =3D [null]; $c =3D 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 (ac=
cepted).  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 mayb=
e a bit hackish compared to what someone much more knowledgeable could impl=
ement.  So I'm not certain if the RFC should be deemed accepted, or, fall i=
nto the howto section 7(3) and go back to discussion (if it is considered a=
 serious issue).

Direction appreciated.

--
Dave

--_000_BY2PR0201MB17840119CEB9BC06307ED2CEBFE20BY2PR0201MB1784_--