Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85725 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78287 invoked from network); 3 Apr 2015 20:59:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Apr 2015 20:59:41 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.200 imap1-2.ox.privateemail.com Received: from [192.64.116.200] ([192.64.116.200:39289] helo=imap1-2.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2C/96-23347-B3FFE155 for ; Fri, 03 Apr 2015 15:59:41 -0500 Received: from localhost (localhost [127.0.0.1]) by imap1.ox.privateemail.com (Postfix) with ESMTP id 349A5B00098; Fri, 3 Apr 2015 16:59:36 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap1.ox.privateemail.com Received: from imap1.ox.privateemail.com ([127.0.0.1]) by localhost (imap1.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j_e4CRB7UTfS; Fri, 3 Apr 2015 16:59:36 -0400 (EDT) Received: from oa-res-26-240.wireless.abdn.ac.uk (oa-res-26-240.wireless.abdn.ac.uk [137.50.26.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imap1.ox.privateemail.com (Postfix) with ESMTPSA id 317E8B00096; Fri, 3 Apr 2015 16:59:34 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Fri, 3 Apr 2015 21:59:33 +0100 Cc: PHP Internals , Nikita Popov Content-Transfer-Encoding: quoted-printable Message-ID: <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> To: Dmitry Stogov X-Mailer: Apple Mail (2.2070.6) Subject: Re: Fix division by zero to throw exception From: ajf@ajf.me (Andrea Faulds) Hi, > On 3 Apr 2015, at 20:46, Dmitry Stogov wrote: >=20 > May be you'll also suggest something regarding bitwise shifts with = negative offset? > Allowing negative offsets using opposite directions would fix = inconsistency, but I remember, you didn't like it. > May be keep WARNING (Bit shift by negative number) and then perform = shift in another direction? > + disable negative shifts at compile-time. I don=E2=80=99t think opposite-direction shifts would work well for a = few reasons. I don=E2=80=99t believe this is normal behaviour in other = languages, for one. Another issue is that << and >> are not actually = opposites, they have different behaviour with respect to signs, so = there=E2=80=99d be ambiguity as to what $x << -$y means (is it the same = as $x >> $y, or does it deal differently with signs?). Negative shifts = being used are usually the result of mistakes, as well, so you want to = inform the user. The main problem, though, is that we previously did something different = if the shift is negative. Having it now produce a warning, means = you=E2=80=99ll see error messages when you run existing code. But = shifting in the opposite direction might change the behaviour of = existing code silently I think the most sensible solution would be to make negative shifts = produce an exception, since they=E2=80=99re really an error, an = unsupported operation. I made them be a warning + return FALSE just = because it matched division. But that=E2=80=99s not ideal and I=E2=80=99d = be fine if it was replaced. Thanks.=20 -- Andrea Faulds http://ajf.me/