Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97688 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93695 invoked from network); 11 Jan 2017 15:43:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2017 15:43:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=dave@mudsite.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dave@mudsite.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.175 as permitted sender) X-PHP-List-Original-Sender: dave@mudsite.com X-Host-Fingerprint: 209.85.217.175 mail-ua0-f175.google.com Received: from [209.85.217.175] ([209.85.217.175:34600] helo=mail-ua0-f175.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/31-55699-E8256785 for ; Wed, 11 Jan 2017 10:43:12 -0500 Received: by mail-ua0-f175.google.com with SMTP id 35so79232139uak.1 for ; Wed, 11 Jan 2017 07:43:10 -0800 (PST) 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; bh=Sv6qtXrG5U6IpaDcd7L4UhvAucJOmbYdoNOkXINBH6w=; b=M6RwcVPuNySbKd9qXoWYqYPOhDC9K+J2GEWCSfHeJwxlfw19wc1KbMNa3i3Zkxao9a bJmNdTIihmNsPNmhHddbaCqYoaj/Jr+bJAzFMrCIOIdTY3dCqp2vkD6/sRxvH0/Kb4Ys j6CUFRvevlHmIaFij3HgMoveThJI4T+Io5ZmGE5xqXP+Z96cJI4RCxHP1zBEwdPkcvR9 9eSvKBgks6OjW1hmNLTXcD+WL4W79OIVQ+hoXV3dQbDX0zyeaNZm5csKNAPnqoJtQtv3 M94cIldCxk7/4616BZ9jaF7c8iHCxHgvwDGd3+1h3QmsI2h/uScE/M1yo2+Z/BukUiOh U7Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Sv6qtXrG5U6IpaDcd7L4UhvAucJOmbYdoNOkXINBH6w=; b=Yv3QZNzjbRpddW7LmQKM3peLQSflkVFJoVT5ty0zf7nSLk+B0UUY8lkVPAKMAEaq1S /XPF10Pa33cIGLM0ONgraqRRBdWOR/cb5LA2hdD8p2sJOFIbEbQrCbcPKTR1p7gBXxmF hEhXpX2P/JQRs/UD5mhHBcRb5SN86SVl/ymdhuYbeGFrT9jwIx5Agb/rtwqwyW16xC4a BDgQXSJf4sRHWrmolEYe1k6LMYBmt7doThDTTjjXjwygtOCxkregqLB0NL3DqKeQ6kY6 vBwSvyXHUV6dFxQHgmmGRDaizK6NK1P7Esp7nn8yg8iYirk76zJJnAwP6/dQmCi8u/qs BWlg== X-Gm-Message-State: AIkVDXLwuhsAHDtD6dNooLiAUhmLoQeNqxxBumISRstRbEoh3ZlacguUCK0iDtP/hpwCWWEyudFIKdTSatQxSQ== X-Received: by 10.176.69.140 with SMTP id u12mr1462041uau.127.1484149387560; Wed, 11 Jan 2017 07:43:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 11 Jan 2017 15:42:56 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary=94eb2c11c0900a18290545d375ac Subject: [RFC][Post-Discussion]: E_WARNING when using array-index on non valid container From: dave@mudsite.com (David Walker) --94eb2c11c0900a18290545d375ac Content-Type: text/plain; charset=UTF-8 [Sorry if this is a second time you get this, but email issues and all] Hi all, Joe had requested renewed discussion on the accepted RFC[1] and my proposed PR[2] be brought forward again for implementation discussion, and to come up with a resolution. The RFC, though accepted, had concerns with implementation specifically related to suppression of multiple warnings for nested access of dim-fetching. I tried to mitigate and resolve the problems raised during the RFC process by ensuring only to raise for non-list() access, and only if the op1 of the next opcode is VAR and is the same opcode as the current one. This seems to suppress all warnings I could think of testing, but am not sure all potential use-cases of when we attempt to fetch for read. Any thoughts on a better implementation, or other use cases that need attention would be appreciated. Cheers -- Dave [1] - wiki [dot] php [dot] net/rfc/notice-for-non-valid-array-container [2] - github [dot] com/php/php-src/pull/2031 --94eb2c11c0900a18290545d375ac--