Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95525 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27722 invoked from network); 1 Sep 2016 00:05:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Sep 2016 00:05:58 -0000 Authentication-Results: pb1.pair.com header.from=dave@mudsite.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dave@mudsite.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: dave@mudsite.com X-Host-Fingerprint: 209.85.217.170 mail-ua0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:35787] helo=mail-ua0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E8/E0-09980-5E077C75 for ; Wed, 31 Aug 2016 20:05:58 -0400 Received: by mail-ua0-f170.google.com with SMTP id i32so117408768uai.2 for ; Wed, 31 Aug 2016 17:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mudsite-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ppElBf55VEzLquvj9elmCrzL20B5wgvzl65ae8FQsuY=; b=E5gGk4ngococO7bXf1+gkRsJ7NqROhb+XIWVP34kzj6yTFdfKDT35caofOF/hFfDzo 3MBCgrBVm7uNg6C6j2fZ39jcZy/AVTJTNfg5IMdDiP8bD7v44EPKO9FXLssY+oleGl5z 4L0GfUgsVp7RZHmcszJkvlTG203AsMBtY0Xl537fEH7CSnGQpWn0BwAluxBUnbrzLZqE 7DGpXnx61acjAEr2uhH5FLEHikEG5Ld5rXLrS/c/bxZzbUk2YOkZXfJEMjSWvjdTBE0P mZqo+ZMpCUfqM+CiTFQ6ndTGNg6I4m/23+aH9ASWEVNokyuKq9JVDrCWZA5GYV1VDolw oAHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ppElBf55VEzLquvj9elmCrzL20B5wgvzl65ae8FQsuY=; b=aTMbP3WJRPFJxJ8M3+9sZYEy6c6GcwT/2JIhfjqbqRrhacyST7uFuzLCGk21LtgUms 5lxHr5jm1099ZYHwhVcs3A/0CsaG9g5nfqUlLU4XAjywamTYS2NbGmbURQFIpFRLJcaV mE2usyMZE659rB5S6soOdz/9i9FQfQhd9Rtpc0Gy3yhj6slFrfkRuiCt73jDFlXUZS7s GAcf1b2Zx3hogXb81D21sJLOsdIqDORxoYbSp0BGZJQG8D6yOCwKv/xoRCNAzPko/W52 5dMFtRv3YlEL/MK5ad2/J0HxHPi+luEOpJPUdkHl6bkJsua2aZM4zUfG2Dgrww+DMLkj Nheg== X-Gm-Message-State: AE9vXwOW1eqaauOKWvbW1+h68XA53hmA1MDbg8TYlXSk0a81LpzNGp4kTUe6SAvit7A5bhJJ7GxXpgAsNY4sTQ== X-Received: by 10.31.49.7 with SMTP id x7mr7640524vkx.158.1472688355034; Wed, 31 Aug 2016 17:05:55 -0700 (PDT) MIME-Version: 1.0 References: <1e6cac8a-e1af-c9e7-a900-a2efda0771dd@gmx.de> In-Reply-To: Date: Thu, 01 Sep 2016 00:05:44 +0000 Message-ID: To: "Christoph M. Becker" , Dmitry Stogov , Marco Pivetta Cc: PHP Internals List , Nikita Popov Content-Type: multipart/alternative; boundary=001a114407d8445d8e053b66fa90 Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess From: dave@mudsite.com (David Walker) --001a114407d8445d8e053b66fa90 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote: > On Wed, Aug 31, 2016 at 7:48 AM David Walker 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 >> 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 >>> > 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>> wrote: >>> >> >>> >> I vote NO, because the implementation introduces more problems than >>> intents to fix. >>> >> >>> >> For example the following code starts to throw exception: >>> >> >>> >> >>> >> >>> > >>> > 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 --001a114407d8445d8e053b66fa90--