From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Checking for loss of information on integer conversion Date: Sun, 18 Feb 2018 22:24:34 +0200 Message-ID: <83fu5y9hbx.fsf@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 1518985376 27798 195.159.176.226 (18 Feb 2018 20:22:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Feb 2018 20:22:56 +0000 (UTC) Cc: 30408@debbugs.gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 18 21:22:52 2018 Return-path: Envelope-to: ged-emacs-devel@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 1enVU0-0006ik-L3 for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 21:22:48 +0100 Original-Received: from localhost ([::1]:46454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enVW2-0004gv-Ee for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 15:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enVVs-0004dt-23 for emacs-devel@gnu.org; Sun, 18 Feb 2018 15:24:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enVVo-0007zp-24 for emacs-devel@gnu.org; Sun, 18 Feb 2018 15:24:44 -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-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222883 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.