From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30408: Checking for loss of information on integer conversion Date: Sun, 18 Feb 2018 22:24:34 +0200 Message-ID: <83fu5y9hbx.fsf__39104.6929326423$1518985416$gmane$org@gnu.org> References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518985416 4657 195.159.176.226 (18 Feb 2018 20:23:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Feb 2018 20:23:36 +0000 (UTC) Cc: 30408@debbugs.gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 18 21:23:31 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enVUQ-0008Lk-IH for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Feb 2018 21:23:14 +0100 Original-Received: from localhost ([::1]:46458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enVWS-0004vs-N0 for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Feb 2018 15:25:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enVWE-0004uJ-MC for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 15:25:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enVWA-00089i-Mz for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 15:25:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42317) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1enVWA-00089S-JP for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 15:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1enVWA-0003f3-D9 for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2018 15:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Feb 2018 20:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30408 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30408-submit@debbugs.gnu.org id=B30408.151898548114041 (code B ref 30408); Sun, 18 Feb 2018 20:25:02 +0000 Original-Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 20:24:41 +0000 Original-Received: from localhost ([127.0.0.1]:50214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enVVo-0003eO-Vs for submit@debbugs.gnu.org; Sun, 18 Feb 2018 15:24:41 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41017) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enVVn-0003eA-O6 for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 15:24:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enVVe-0007iI-GB for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 15:24:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enVVe-0007i8-BO; Sun, 18 Feb 2018 15:24:30 -0500 Original-Received: from [176.228.60.248] (port=1510 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1enVVd-0001Iu-2S; Sun, 18 Feb 2018 15:24:30 -0500 In-reply-to: <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> (message from Paul Eggert on Sun, 18 Feb 2018 12:04:20 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143439 Archived-At: > From: Paul Eggert > Cc: emacs-devel@gnu.org, 30408@debbugs.gnu.org > Date: Sun, 18 Feb 2018 12:04:20 -0800 > > > Emacs Lisp is not used to write software that controls > > aircraft and spaceships > > Actually, I maintain Emacs Lisp code that controls timestamps used in aircraft > and spaceships. I'm not saying that Emacs itself runs the aircraft and > spaceships, but it definitely is used to develop software and data used there. > As luck would have it, I'm currently engaged in an email thread about time > transfer between Earth and Mars (yes, this is really a thing and people are > trying to do it with millisecond precision) that is related to a project where I > regularly use Emacs Lisp. See the thread containing this message: Interesting, but not really relevant to the issue at hand, IMO. I was talking about real-time control, not off-line calculations. And I did propose to have this feature as opt-in, so the kind of calculations that transfer me to Mars could still be held safely and accurately. > > More generally, why signaling an error by default in this case is a > > good idea? ... That would > > be similar to behavior of equivalent constructs in C programs > > Sure, and C compilers typically issue diagnostics for situations similar to > what's in Bug#30408. For example, for this C program: > > int a = 18446744073709553664; > > GCC issues a diagnostic, whereas for the similar Emacs Lisp program: > > (setq b 18446744073709553664) > > Emacs silently substitutes a number that is off by 2048. I'm okay with flagging such constants during byte compilation. I was talking only about run-time diagnostics, not compile-time diagnostics. > When people write a floating-point number they naturally expect it to have some > fuzz. But when they write an integer they expect it to be represented exactly, > and not to be rounded. That is true, but Emacs behaved like it does today for many years, and I'm worried by the possible breakage such a significant behavior change could have, including on our own code.