Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87019 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97300 invoked from network); 4 Jul 2015 22:37:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2015 22:37:44 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.162 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.162 blu004-omc4s23.hotmail.com Received: from [65.55.111.162] ([65.55.111.162:59563] helo=BLU004-OMC4S23.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/A1-02984-73068955 for ; Sat, 04 Jul 2015 18:37:44 -0400 Received: from BLU436-SMTP245 ([65.55.111.137]) by BLU004-OMC4S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 4 Jul 2015 15:37:40 -0700 X-TMN: [HtHbJ/PWRIYvKJMTx87ZWzEHt2aJA77j] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_0390F59B-76BD-4D61-9395-9CA8AB2B2962" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Sun, 5 Jul 2015 00:37:33 +0200 CC: Sherif Ramadan , =?utf-8?Q?Jakub_Kub=C3=AD=C4=8Dek?= , Dmitry Stogov , PHP Internals , Nikita Popov , Aaron Piotrowski , Levi Morrison References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> To: Keller Niklas , Andrea Faulds X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 04 Jul 2015 22:37:38.0130 (UTC) FILETIME=[078FBB20:01D0B6AA] Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2) From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_0390F59B-76BD-4D61-9395-9CA8AB2B2962 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > Am 4.7.2015 um 23:09 schrieb Niklas Keller : >=20 > 2015-07-04 22:56 GMT+02:00 Sherif Ramadan >: > Hey guys, >=20 > I'm proposing that we reconsider removing the warning from floating = point > division and here's why. >=20 > While IEEE 754 defines special values for floating point arithmetic = when > division by zero occurs, there's nothing stopping the language from > providing useful error information to the user, which may help them = debug > potentially buggy code. It's true that it's not exceptional since = there is > now well defined behavior in the case of changing division by zero to = IEEE > 754 standard in PHP. However, PHP didn't actually distinguish between > integer division and floating point division prior to intdiv. So in = the > case of division by zero the warning was useful to help someone catch = their > mistake. >=20 > Now, the onus is on the person writing the code to decipher whether or = not > they created a potential division by zero scenario by deducing how = they > arrived at INF at some point in their code. This is creating an = unnecessary > burden when we've always provided the user with the useful error > information in the past. I'm not sure why we should remove it now, but > based on this conversation I can see that the confusion resonates = around > this urge to convert the warning to an exception and the conflict of = it not > being exceptional (in the case of floating point math) since there is = now > well defined behavior. >=20 > So my conclusion is that... >=20 > Yes, it's not exceptional. No, we shouldn't throw an exception for = division > by zero in floating point arithmetic. No, we shouldn't remove the = warning > since it still provides useful information to the person debugging the > code. Debugging the code without this warning can be a monstrosity = since > you won't necessarily know at which point in a compounded operation = the > division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX = creates > an overflow resulting in INF. Though 0 / INF results in 0. So an = operation > like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 = in > one particular case, makes both hunting down and reproducing the bug = quite > difficult without some direction. The warning has historically = provided > this direction in the past and I believe that removing it now will = only > further the confusion. >=20 > I don't think people actually care about whether or not we keep the > warning. I think what they would care about more is the consistency of = the > return value and defined behavior, which I believe we have already > addressed very well. >=20 > +1, I fully agree. It's not exceptional, but it's potentially buggy = code and should > therefore produce a warning instead of just returning INF. >=20 > I assume, most developers don't want to deal with INF in their code. = If there's > a warning, they can convert it to an exception which would not be = possible > without it. >=20 > Regards, Niklas=20 Generally, that was my first proposal, and I=E2=80=99d still support it = and would like to implement it, when other people are agreeing here. As Andrea objected to that ( / floating point division should be handled = like IEEE 754=E2=80=A6), I=E2=80=99d like to wait for further opinions = on this before committing anything in this direction. Ideally, I=E2=80=99d prefer to have that solved until Monday evening so = that I can change it before beta 1 tagging. Thanks, Bob --Apple-Mail=_0390F59B-76BD-4D61-9395-9CA8AB2B2962--