Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87020 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99513 invoked from network); 4 Jul 2015 22:51:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2015 22:51:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.216 imap10-3.ox.privateemail.com Received: from [192.64.116.216] ([192.64.116.216:58202] helo=imap10-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B1/00-33330-96368955 for ; Sat, 04 Jul 2015 18:51:21 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id E2A1E2400C2; Sat, 4 Jul 2015 18:51:17 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap10.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap10.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5XaD20IQtLIW; Sat, 4 Jul 2015 18:51:17 -0400 (EDT) Received: from [192.168.0.3] (unknown [90.211.5.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 1C73D2400D0; Sat, 4 Jul 2015 18:51:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) In-Reply-To: Date: Sat, 4 Jul 2015 23:50:35 +0100 Cc: =?utf-8?Q?Jakub_Kub=C3=AD=C4=8Dek?= , Dmitry Stogov , Bob Weinand , PHP Internals , Nikita Popov , Aaron Piotrowski , Levi Morrison Content-Transfer-Encoding: quoted-printable Message-ID: References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> To: Sherif Ramadan X-Mailer: Apple Mail (2.2102) Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2) From: ajf@ajf.me (Andrea Faulds) Hey Sherif, > On 4 Jul 2015, at 21:56, Sherif Ramadan = wrote: >=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. Yeah, keeping it around makes sense. Thing is, if it=E2=80=99s a problem, you can silence it with @, so @($a = / $b). If that=E2=80=99s slow, we could optimise it (make it call = div_function_no_error or something?) Thanks. -- Andrea Faulds http://ajf.me/