Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97520 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84153 invoked from network); 5 Jan 2017 15:45:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2017 15:45:08 -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.213.52 as permitted sender) X-PHP-List-Original-Sender: dave@mudsite.com X-Host-Fingerprint: 209.85.213.52 mail-vk0-f52.google.com Received: from [209.85.213.52] ([209.85.213.52:33644] helo=mail-vk0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/D4-55609-20A6E685 for ; Thu, 05 Jan 2017 10:45:07 -0500 Received: by mail-vk0-f52.google.com with SMTP id 137so302340046vkl.0 for ; Thu, 05 Jan 2017 07:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mudsite-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bbrKPsn/YYmUB3Ojraofz3duvL9ObmohQBsDn6RtiBM=; b=rpqHQVPa6IsYMKzZq+dsBCuPlh8D0VKz6Lm9aLEqCexFguPN5xJB02I7z+z0McY22y RJvKFAw3OTl15YuVbtk5FsplpkTh5tSpABzRpLZWzJoR15kHsPyXqIr5Tu5xzBfrwlo+ ksY0C+/qlZ48jjEjmKDFuS+RyLid0bK0M0Z+HLkLSun84t8QHNZTkCrkaFvZAXKyWdQ3 mLha0AruCAK/wlRp+GTmbmgj3wqF19wBkC5XK8+iGqoyadMMInhvKn6jaNOEsnr2MWJU lA6t5TrqQyOvQ5cRyjhb80Yw/MM++Kf0X6U+hJB9fDlYVql3yL3sdJ/pi7ylKZFXvemh uk+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bbrKPsn/YYmUB3Ojraofz3duvL9ObmohQBsDn6RtiBM=; b=A3ZC7ZoZc+4dU3KIUTTuVEHNOZhgKrxx5BFGYbWgC/f5kkipp+oOxA2rjTZOlSqnGd u2oT2aQbq1hIz7qAynz6QfSHQT042Lsm0cCoFGzNdmLji7Q5OxS8noaaZbKcyA886qrD xKQrnaMgyXT4PXe96EcnQdFsXUaJkbkM36ZLPjTGlfZbjQpCg/OSZA8Sny0fyA6Wf11y MoVUZaJNtiiT6aII1D+fLFMPjTBWH4LYqxeO71r6kGbXEMaBvtUbzB9UoCmTzWUBjtuO A8u7LilrRtScRruspFMUQNWVWvVK2r54eSxqa3tyZN+Lj3LvRDGQtq07QggIMITXcW/L 8oKg== X-Gm-Message-State: AIkVDXJP/7UhlOq8Sx85b01EtBOWUHEQs+sKHhFFzPT6gDlPG3Hrv88Z4faopnGm7EUb5tWkv7R4+AX8jPcY+Q== X-Received: by 10.31.194.205 with SMTP id s196mr25722341vkf.101.1483631103408; Thu, 05 Jan 2017 07:45:03 -0800 (PST) MIME-Version: 1.0 Date: Thu, 05 Jan 2017 15:44:52 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary=001a11439cf0e647d805455ac86e Subject: [RFC][Post-Discussion]: E_WARNING when using array-index on non valid container From: dave@mudsite.com (David Walker) --001a11439cf0e647d805455ac86e Content-Type: text/plain; charset=UTF-8 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 --001a11439cf0e647d805455ac86e--