Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85729 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86092 invoked from network); 3 Apr 2015 21:34:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Apr 2015 21:34:07 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.212.171 mail-wi0-f171.google.com Received: from [209.85.212.171] ([209.85.212.171:38160] helo=mail-wi0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/38-23347-F470F155 for ; Fri, 03 Apr 2015 16:34:07 -0500 Received: by wiun10 with SMTP id n10so4968343wiu.1 for ; Fri, 03 Apr 2015 14:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ZXEt7XHdN8jDmDba7Y8EWPD4HPq0ilYXqqGUbpEaJM=; b=tg9VycnEZo5RuzPhxoBJ7fdinr40Q/2UTEgLmH6+xUTZbDVecpQrp4xx8AZ3CXvv5M fftC1GcCKlR0G3GQvyQ7a9hbHMznWdZ9L6B9kxgV4zsh8xLETpSRmOEnAcDPfV26+U+j oMntcTVfR27Xr90FTiiIjV1bA0JbdVXOUi9oX5A6E7ix+t6BEnqGnBzUhLaxEIp48uK8 aEe3RL/XvA5VXc1lTkAJtVfuDpuVdOma/ABhuH+4NJYWxo1MbsxBMtl6oFeK8OaGpK8x rTURS+QsJ1iGb7cLekGI5EeDdJRGZjw5eJw9PADiHrc9hFhm/ZiqXMPooxvL4CQOBmUH U2GQ== MIME-Version: 1.0 X-Received: by 10.180.10.234 with SMTP id l10mr9095732wib.27.1428096844272; Fri, 03 Apr 2015 14:34:04 -0700 (PDT) Received: by 10.27.85.216 with HTTP; Fri, 3 Apr 2015 14:34:04 -0700 (PDT) In-Reply-To: References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> Date: Fri, 3 Apr 2015 23:34:04 +0200 Message-ID: To: Dmitry Stogov Cc: Andrea Faulds , PHP Internals Content-Type: multipart/alternative; boundary=001a11c2b3481b996c0512d8b511 Subject: Re: Fix division by zero to throw exception From: nikita.ppv@gmail.com (Nikita Popov) --001a11c2b3481b996c0512d8b511 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2015 at 11:13 PM, Dmitry Stogov wrote: > > > > On Fri, Apr 3, 2015 at 11:59 PM, Andrea Faulds wrote: > >> Hi, >> >> > On 3 Apr 2015, at 20:46, Dmitry Stogov wrote: >> > >> > 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 fe= w >> reasons. I don=E2=80=99t believe this is normal behaviour in other langu= ages, for >> one. Another issue is that << and >> are not actually opposites, they ha= ve >> different behaviour with respect to signs, so there=E2=80=99d be ambigui= ty 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 res= ult >> 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 unsuppor= ted >> operation. I made them be a warning + return FALSE just because it match= ed >> division. But that=E2=80=99s not ideal and I=E2=80=99d be fine if it was= replaced. >> > > OK. Exception is fine. > > So the summary: > > 1) division by zero produces a warning and +/-INF IS_DOUBLE. Compile-time > evaluation is disabled. > > 2) Negative shift produces Exception.Compile-time evaluation is disabled. > > 3) Modulo by zero produces Exception.Compile-time evaluation is disabled. > > Everything right? > Don't think we need to disable compile-time evaluation for 2) and 3). It'll just end up being a compile error in that case. I think if you have 1 % 0 occurring in your code literally, it's better to have the compile fail rather than getting (or not getting) a runtime exception. Nikita --001a11c2b3481b996c0512d8b511--