Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106721 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 53402 invoked from network); 28 Aug 2019 14:26:47 -0000 Received: from unknown (HELO mail.gna.ch) (62.12.172.119) by pb1.pair.com with SMTP; 28 Aug 2019 14:26:47 -0000 Received: from [10.183.2.190] (unknown [217.192.174.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 09EB4210E1; Wed, 28 Aug 2019 13:58:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Wed, 28 Aug 2019 13:58:54 +0200 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <8F022993-6021-4AEC-A1E9-9CC04F85C856@cschneid.com> References: To: Nikita Popov X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings From: cschneid@cschneid.com (Christian Schneider) Am 28.08.2019 um 13:10 schrieb Nikita Popov : > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote: >> Specifically on undefined variables, the way we deal with them has = little >> to do with register_globals. It's behavior you can find in other = dynamic >> languages (e.g. Perl), and allows for certain code patterns (which = rely on >> the automatic creation of a variable whenever it's used in write = context, >> and on a default known-in-advance value in case it's used in a read >> context). It's fine not to like this behavior or the code patterns = that >> commonly rely on it (e.g., @$foo++), but it's intentional and isn't = related >> to any historical reasons. >=20 > This argument makes sense for arrays and objects (and I don't promote > undefined index/property to exceptions for that reason), but I don't = think > it holds any water for simple variables. Writing @$counts[$key]++ is a = lazy > way to count values and avoid ugly boilerplate for if > (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] =3D = 1; }. > But @$foo++ is just a really bad way of writing either $foo++ or $foo = =3D 1. > Outside of variable variables, the concept of a conditionally defined > variable just doesn't make a lot of sense. We often use the pattern $a .=3D "xy" or $a[] =3D "xy" and requiring to = initialise leads to either boiler-plate code in often very simple = functions or even worse to write the first one as $a =3D "xy" and $a =3D = ["xy"] which both hurt symmetry and extensibility (you need to change = two places if you want to add a new first entry). We are already = suppressing the E_NOTICE for this as the pattern is too useful to fill = our logs. Your simple typo in variable names can be caught well enough by a static = analyser, we have a simplistic one in out git commit hook which more = than does the job for us. And it does it even better in your average = case as it also catches typos in rare code paths not executed by your = tests. And no, don't say "make sure you have 100% code coverage", that = is a myth. Summary: Promote E_NOTICE to E_WARNINGS, fine, make them abort code = execution: Don't do it, don't break our code. For people promoting a stricter PHP mode: Just fix your code if it = caused an E_NOTICE/E_WARNING, you don't need an Exception for that. And = I don't buy the whole security argument, code has to be secure on a = whole different level than undefined variables. - Chris