From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 10 02:02:42 2018 Received: (at submit) by debbugs.gnu.org; 10 Feb 2018 07:02:42 +0000 Received: from localhost ([127.0.0.1]:35994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekPBJ-00062W-UM for submit@debbugs.gnu.org; Sat, 10 Feb 2018 02:02:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekOYx-00053i-UA for submit@debbugs.gnu.org; Sat, 10 Feb 2018 01:23:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekOYr-0000bP-PL for submit@debbugs.gnu.org; Sat, 10 Feb 2018 01:22:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58007) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ekOYr-0000b9-KQ for submit@debbugs.gnu.org; Sat, 10 Feb 2018 01:22:57 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekOYq-0008Ep-Co for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 01:22:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekOYp-0000Yx-4i for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 01:22:56 -0500 Received: from mail-io0-x22f.google.com ([2607:f8b0:4001:c06::22f]:37472) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ekOYp-0000YQ-0B for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 01:22:55 -0500 Received: by mail-io0-x22f.google.com with SMTP id f89so12089572ioj.4 for ; Fri, 09 Feb 2018 22:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RzJRBGH1BN1NXbidAQlLGOM8yezKyZeAhcOMb3AhYpY=; b=U9yBaHDssDnT/3tuJpYcp7AU9isYinuusMPB7k0ZoIpdBG659cZPBtjEzvhjx7dAHn hSqzODehJ/C6L1TFebSuXDA0vuUXXVuYQWhv25YfBmORWa645/U7CIW+HJ3QU+X/VzaJ og/+cOKu52r5NrrNSy3zndZMKK3EsCzvHPPTlfEXJ4UCLJMTzLFvQ/zu/U3zexaMgF+O dUuKDCiM+rdxv5krO4GGm6pSfT+HkMEnQErYum4IDwDpHhMhlG9PzEBRolE1PRu2f87z TgTxkUzEZezlVQIXjeZy1NPeLwbGYX1bCIltlF3Vg3SU+2jqjxErNjISOKAlFZv3Vba/ JpAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RzJRBGH1BN1NXbidAQlLGOM8yezKyZeAhcOMb3AhYpY=; b=dATUwNLhTkwxEDy4UOr6oCR2ZRUCWdPMQpaaVF2gWbcMONDIVLwQi/2SML3jJYL7Ri 7p8X3Ys7lc4LORHdXMgBahtdKUH3KRen04YIxoZsZgxne1Jus42j0907VqQw7nfla/oN ZUTRPxcpogL/pSzloCUKQ/6se4UShTOTFLExBAM8AFh6BWX/2io+9SIZLZgbxOrU7j5T 0OblDpkQQOs4SSYKntZ/Dj5JAFrr9naGwO99kUX6SShFka4/VjtRWipZFBHxv4rDNXhX w2S4KJw1L9dTVsYBDieym4kPbbaivc6T73wDUO3po79HiKEr/PbCX70JI+MFgDsPHiUq 3OuQ== X-Gm-Message-State: APf1xPBOl5U+LixTwbT8alLGTbfx1MZ1z4E9hYEOG80sklUzXq/Qdfzw UIf6TVHVrLtOr3WjJX8SCMQ7YYmfeqZEuDqovwQp0m8+ X-Google-Smtp-Source: AH8x2253F+WAQzQn7rsqiJNbdQzOxuCQK8VtKt09KCfNogUKPBs+jNQPQ83C8QCVA1PANSmGVb0d9Uce/crxKAhpr9s= X-Received: by 10.107.161.205 with SMTP id k196mr5943328ioe.253.1518243773758; Fri, 09 Feb 2018 22:22:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.184.85 with HTTP; Fri, 9 Feb 2018 22:22:53 -0800 (PST) From: David Sitsky Date: Sat, 10 Feb 2018 17:22:53 +1100 Message-ID: Subject: 24.5; (format "%x" large-number) produces incorrect results To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="001a11410090d141fb0564d5acda" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 10 Feb 2018 02:02:40 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --001a11410090d141fb0564d5acda Content-Type: text/plain; charset="UTF-8" I wrote this originally on https://emacs.stackexchange.com/questions/38710/why-does-format-x-some-large-number-produces-incorrect-results and a poster recommended I mention this here. I wanted the hexadecimal string for a large integer such as below: (format "%x" 2738188573457603759) This returns 2600000000f95c00 which is incorrect, it should be 2600000000f95caf. The value of most-positive-fixnum on my box is 0x1fffffffffffffff which is less than the number I'm supplying above. As a user I'm a bit baffled what is happening. The manual indicates integers larger than this range are converted to a floating-point number which is a concern for precision but I suspect this is what is biting me here? I should have known there was an issue with this number since normally I evaluate them directly using eval-last-sexp and it didn't show the octal/hex variants.. :) I wonder why Emacs Lisp doesn't support bignums by default, so precision would not be an issue? --001a11410090d141fb0564d5acda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wrote this originally on=C2=A0https://emacs.stackexchange.com/questions/38710/why-d= oes-format-x-some-large-number-produces-incorrect-results and a poster = recommended I mention this here.

I wanted the hexadecimal str= ing for a large integer such as below:

(format "%x" 273818= 8573457603759)

This returns 2600000000f95c00 which is incorrect, it = should be 2600000000f95caf.

The value of most-positive-fixnum on my = box is 0x1fffffffffffffff which is less than the number I'm supplying a= bove.

As a user I'm a bit baffled what is happening. The manual = indicates integers larger than this range are converted to a floating-point= number which is a concern for precision but I suspect this is what is biti= ng me here?

I should have known there was an issue with this number = since normally I evaluate them directly using eval-last-sexp and it didn= 9;t show the octal/hex variants.. :)

I wonder why Emacs Lisp doesn&#= 39;t support bignums by default, so precision would not be an issue?
--001a11410090d141fb0564d5acda-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 21:49:43 2018 Received: (at 30408) by debbugs.gnu.org; 12 Feb 2018 02:49:43 +0000 Received: from localhost ([127.0.0.1]:38787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el4Ba-0000Qe-OI for submit@debbugs.gnu.org; Sun, 11 Feb 2018 21:49:42 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el4BY-0000QR-NE for 30408@debbugs.gnu.org; Sun, 11 Feb 2018 21:49:41 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D05901600F3; Sun, 11 Feb 2018 18:49:34 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ozSfB8eBarcA; Sun, 11 Feb 2018 18:49:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2CCD8160156; Sun, 11 Feb 2018 18:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pP_7EYS5m5LZ; Sun, 11 Feb 2018 18:49:34 -0800 (PST) Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0C7DC1600F3; Sun, 11 Feb 2018 18:49:34 -0800 (PST) To: David Sitsky From: Paul Eggert Subject: Re: 24.5; (format "%x" large-number) produces incorrect results Organization: UCLA Computer Science Department Message-ID: <60284cf8-d1b4-a1c6-5d06-a21a7085c89c@cs.ucla.edu> Date: Sun, 11 Feb 2018 18:49:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I wonder why Emacs Lisp doesn't support bignums by default, so precision > would not be an issue? Nobody has gotten around to implementing it. It'd be nice if someone did. It is a wishlist item, so I'll mark this bug report as wishlist priority. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 21:50:28 2018 Received: (at control) by debbugs.gnu.org; 12 Feb 2018 02:50:28 +0000 Received: from localhost ([127.0.0.1]:38791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el4CK-0000S2-2S for submit@debbugs.gnu.org; Sun, 11 Feb 2018 21:50:28 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:32822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el4CI-0000Rp-Jm for control@debbugs.gnu.org; Sun, 11 Feb 2018 21:50:26 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3A6901600F3 for ; Sun, 11 Feb 2018 18:50:21 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HI7d63d3lKpM for ; Sun, 11 Feb 2018 18:50:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8F87F160156 for ; Sun, 11 Feb 2018 18:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oOvIggoga10E for ; Sun, 11 Feb 2018 18:50:20 -0800 (PST) Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 691231600F3 for ; Sun, 11 Feb 2018 18:50:20 -0800 (PST) To: control@debbugs.gnu.org From: Paul Eggert Subject: 30408 is wishlist Organization: UCLA Computer Science Department Message-ID: Date: Sun, 11 Feb 2018 18:50:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) severity 30408 wishlist From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 12 00:04:51 2018 Received: (at 30408) by debbugs.gnu.org; 12 Feb 2018 05:04:51 +0000 Received: from localhost ([127.0.0.1]:38808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el6IL-0005mq-9E for submit@debbugs.gnu.org; Mon, 12 Feb 2018 00:04:50 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:35130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1el6IJ-0005mZ-M0 for 30408@debbugs.gnu.org; Mon, 12 Feb 2018 00:04:48 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w1C52FLD006562; Mon, 12 Feb 2018 05:04:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=7wvJCafQpOgYYMgVdqtHIgDuVgu81xr5SLNjACzJwc8=; b=fyJEgyNC0/eLjDYKiSJlZe1vKKEZmG0/An5WSVnzMSO7McDj7Vsm3n3bGeovleLqc+U3 A57d/gySLkbxdbRu5bHK3M5ROGyfRnYFQo1Z4D3+GghG1rA6dbUIdJIbw6yJrgAVgxQ3 +L+oZrtHh8mJxXWTx8e7PISNfKmE0FeCrtyjwA/TzNypdGDOAK9F55L8NBdRvwwQUbs1 /jxnAUBgVKEsxf3pELOI61SOWMX9jF6nLmx8qKm2xtYgIaKGmvVzwo8Fa2TiRQn2wFG4 gcQlH14tVpAM4f7aKRokBs6pWQoAdvASBdUsvDvkgAg6Y5YZnq31wC5DTnCqaBrHC0xA TA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2g33gyg587-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Feb 2018 05:04:33 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w1C4uXee027702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Feb 2018 04:56:33 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w1C4uXQt009144; Mon, 12 Feb 2018 04:56:33 GMT MIME-Version: 1.0 Message-ID: <856eb7d4-ed47-4a5c-8747-6334ab37638a@default> Date: Sun, 11 Feb 2018 20:56:32 -0800 (PST) From: Drew Adams To: Paul Eggert , David Sitsky Subject: RE: bug#30408: 24.5; (format "%x" large-number) produces incorrect results References: <60284cf8-d1b4-a1c6-5d06-a21a7085c89c@cs.ucla.edu> In-Reply-To: <60284cf8-d1b4-a1c6-5d06-a21a7085c89c@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4639.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8802 signatures=668668 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=819 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802120063 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > > I wonder why Emacs Lisp doesn't support bignums by default, so > > precision would not be an issue? >=20 > Nobody has gotten around to implementing it. It'd be nice if someone did. > It is a wishlist item, so I'll mark this bug report as wishlist priority. It's probably a duplicate bug. This has been requested in the past - perhaps more than once. And there has been some discussion of it. I don't have a reference, however. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 17 20:08:33 2018 Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 01:08:33 +0000 Received: from localhost ([127.0.0.1]:48781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enDSy-0004jQ-Gv for submit@debbugs.gnu.org; Sat, 17 Feb 2018 20:08:32 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enDSw-0004jB-Hv for 30408@debbugs.gnu.org; Sat, 17 Feb 2018 20:08:31 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A7BC11615B2; Sat, 17 Feb 2018 17:08:24 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Sjz7YqbkZIjw; Sat, 17 Feb 2018 17:08:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6B14E1615E5; Sat, 17 Feb 2018 17:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k6-E-f_T47eq; Sat, 17 Feb 2018 17:08:23 -0800 (PST) Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2265B1615B2; Sat, 17 Feb 2018 17:08:23 -0800 (PST) Subject: Re: bug#30408: 24.5; (format "%x" large-number) produces incorrect results To: Drew Adams , David Sitsky References: <60284cf8-d1b4-a1c6-5d06-a21a7085c89c@cs.ucla.edu> <856eb7d4-ed47-4a5c-8747-6334ab37638a@default> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <6e24717b-8fad-b9bf-0c92-d3c9d958bfc6@cs.ucla.edu> Date: Sat, 17 Feb 2018 17:08:22 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <856eb7d4-ed47-4a5c-8747-6334ab37638a@default> Content-Type: multipart/mixed; boundary="------------AC1E2F59C65988B6D17F2792" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------AC1E2F59C65988B6D17F2792 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This kind of bug has bitten me before, so I think it's worthwhile for Ema= cs to=20 defend against it better. Proposed patch attached. Although this patch do= esn't=20 address the major problem here (which is that Emacs lacks bignums), it do= es=20 cause Emacs to respond better to large numbers, by not losing information= when=20 it is reading or printing integers. With this patch, one cannot evaluate (format "%x" 2738188573457603759) be= cause=20 the Lisp reader signals an error when it sees the unrepresentable integer= =20 2738188573457603759, instead of silently substituting a different number.= =20 Another example: (format "%d" 18446744073709551616) now returns=20 "18446744073709551616" instead of the quite-wrong "9223372036854775807". --------------AC1E2F59C65988B6D17F2792 Content-Type: text/x-patch; name="0001-Avoid-losing-info-when-converting-integers.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Avoid-losing-info-when-converting-integers.patch" =46rom e1865be990e1a520feddc07507a71916d097d633 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 17 Feb 2018 16:45:17 -0800 Subject: [PATCH] Avoid losing info when converting integers This fixes some glitches with large integers (Bug#30408). * doc/lispref/numbers.texi (Integer Basics): Say that decimal integers out of fixnum range must be representable exactly as floating-point. * etc/NEWS: Mention this. * src/data.c (syms_of_data): Add Qinexact_error. * src/editfns.c (styled_format): Use %.0f when formatting %d or %i values outside machine integer range, to avoid losing info. Signal an error for %o or %x values that are too large to be formatted, to avoid losing info. * src/lread.c (string_to_number): When converting an integer-format string to floating-point, signal an error if info is lost. --- doc/lispref/numbers.texi | 8 +++-- etc/NEWS | 9 +++++ src/data.c | 1 + src/editfns.c | 93 ++++++++++++++++++++----------------------= ------ src/lread.c | 14 ++++++++ 5 files changed, 67 insertions(+), 58 deletions(-) diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index e692ee1cc2..252aafd8fd 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -53,9 +53,11 @@ Integer Basics chapter assume the minimum integer width of 30 bits. @cindex overflow =20 - The Lisp reader reads an integer as a sequence of digits with optional= -initial sign and optional final period. An integer that is out of the -Emacs range is treated as a floating-point number. + The Lisp reader can read an integer as a nonempty sequence of +decimal digits with optional initial sign and optional final period. +A decimal integer that is out of the Emacs range is treated as +floating-point if it can be represented exactly as a floating-point +number. =20 @example 1 ; @r{The integer 1.} diff --git a/etc/NEWS b/etc/NEWS index 8db638e5ed..36cbcf6500 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -248,6 +248,12 @@ as new-style, bind the new variable 'force-new-style= -backquotes' to t. 'cl-struct-define' whose name clashes with a builtin type (e.g., 'integer' or 'hash-table') now signals an error. =20 +** When formatting a floating-point number as an octal or hexadecimal +integer, Emacs now signals an error if the number is too large for the +implementation to format. When reading an integer outside Emacs +fixnum range, Emacs now signals an error if the integer cannot be +represented exactly as a floating-point number. See Bug#30408. + =0C * Lisp Changes in Emacs 27.1 =20 @@ -289,6 +295,9 @@ remote systems, which support this check. If the optional third argument is non-nil, 'make-string' will produce a multibyte string even if its second argument is an ASCII character. =20 +** (format "%d" X) no longer mishandles floating-point X values that +do not fit in a machine integer (Bug#30408). + ** New JSON parsing and serialization functions 'json-serialize', 'json-insert', 'json-parse-string', and 'json-parse-buffer'. These are implemented in C using the Jansson library. diff --git a/src/data.c b/src/data.c index 72abfefb01..8856583f13 100644 --- a/src/data.c +++ b/src/data.c @@ -3729,6 +3729,7 @@ syms_of_data (void) DEFSYM (Qrange_error, "range-error"); DEFSYM (Qdomain_error, "domain-error"); DEFSYM (Qsingularity_error, "singularity-error"); + DEFSYM (Qinexact_error, "inexact-error"); DEFSYM (Qoverflow_error, "overflow-error"); DEFSYM (Qunderflow_error, "underflow-error"); =20 diff --git a/src/editfns.c b/src/editfns.c index 96bb271b2d..d26549ddb8 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -4563,32 +4563,30 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) and with pM inserted for integer formats. At most two flags F can be specified at once. */ char convspec[sizeof "%FF.*d" + max (INT_AS_LDBL, pMlen)]; - { - char *f =3D convspec; - *f++ =3D '%'; - /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ - *f =3D '+'; f +=3D plus_flag; - *f =3D ' '; f +=3D space_flag; - *f =3D '#'; f +=3D sharp_flag; - *f++ =3D '.'; - *f++ =3D '*'; - if (float_conversion) - { - if (INT_AS_LDBL) - { - *f =3D 'L'; - f +=3D INTEGERP (arg); - } - } - else if (conversion !=3D 'c') - { - memcpy (f, pMd, pMlen); - f +=3D pMlen; - zero_flag &=3D ! precision_given; - } - *f++ =3D conversion; - *f =3D '\0'; - } + char *f =3D convspec; + *f++ =3D '%'; + /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ + *f =3D '+'; f +=3D plus_flag; + *f =3D ' '; f +=3D space_flag; + *f =3D '#'; f +=3D sharp_flag; + *f++ =3D '.'; + *f++ =3D '*'; + if (float_conversion) + { + if (INT_AS_LDBL) + { + *f =3D 'L'; + f +=3D INTEGERP (arg); + } + } + else if (conversion !=3D 'c') + { + memcpy (f, pMd, pMlen); + f +=3D pMlen; + zero_flag &=3D ! precision_given; + } + *f++ =3D conversion; + *f =3D '\0'; =20 int prec =3D -1; if (precision_given) @@ -4630,29 +4628,18 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) } else if (conversion =3D=3D 'd' || conversion =3D=3D 'i') { - /* For float, maybe we should use "%1.0f" - instead so it also works for values outside - the integer range. */ - printmax_t x; if (INTEGERP (arg)) - x =3D XINT (arg); + { + printmax_t x =3D XINT (arg); + sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); + } else { - double d =3D XFLOAT_DATA (arg); - if (d < 0) - { - x =3D TYPE_MINIMUM (printmax_t); - if (x < d) - x =3D d; - } - else - { - x =3D TYPE_MAXIMUM (printmax_t); - if (d < x) - x =3D d; - } + strcpy (f - pMlen - 1, "f"); + prec =3D 0; + double x =3D XFLOAT_DATA (arg); + sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } - sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } else { @@ -4663,22 +4650,18 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) else { double d =3D XFLOAT_DATA (arg); - if (d < 0) - x =3D 0; - else - { - x =3D TYPE_MAXIMUM (uprintmax_t); - if (d < x) - x =3D d; - } + if (! (0 <=3D d && d < TYPE_MAXIMUM (uprintmax_t))) + xsignal1 (Qoverflow_error, arg); + x =3D d; } sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } =20 /* Now the length of the formatted item is known, except it omits= padding and excess precision. Deal with excess precision - first. This happens only when the format specifies - ridiculously large precision. */ + first. This happens when the format specifies + ridiculously large precision, or when %d or %i has + nonzero precision and formats a float. */ ptrdiff_t excess_precision =3D precision_given ? precision - prec : 0; ptrdiff_t leading_zeros =3D 0, trailing_zeros =3D 0; diff --git a/src/lread.c b/src/lread.c index d009bd0cd2..cfeaac8030 100644 --- a/src/lread.c +++ b/src/lread.c @@ -3794,6 +3794,20 @@ string_to_number (char const *string, int base, bo= ol ignore_trailing) if (! value) value =3D atof (string + signedp); =20 + if (! float_syntax) + { + /* Check that converting the integer-format STRING to a + floating-point number does not lose info. See Bug#30408. */ + char const *bp =3D string + signedp; + while (*bp =3D=3D '0') + bp++; + char checkbuf[DBL_MAX_10_EXP + 2]; + int checkbuflen =3D sprintf (checkbuf, "%.0f", value); + if (! (cp - bp - !!(state & DOT_CHAR) =3D=3D checkbuflen + && memcmp (bp, checkbuf, checkbuflen) =3D=3D 0)) + xsignal1 (Qinexact_error, build_string (string)); + } + return make_float (negative ? -value : value); } =20 --=20 2.14.3 --------------AC1E2F59C65988B6D17F2792-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 18 12:14:41 2018 Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 17:14:42 +0000 Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enSXx-0007TY-NX for submit@debbugs.gnu.org; Sun, 18 Feb 2018 12:14:41 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enSXv-0007TM-OZ for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 12:14:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enSXp-0007NF-Fy for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 12:14:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enSXl-0007L1-5S; Sun, 18 Feb 2018 12:14:29 -0500 Received: from [176.228.60.248] (port=1261 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1enSXk-00014w-IO; Sun, 18 Feb 2018 12:14:28 -0500 Date: Sun, 18 Feb 2018 19:14:33 +0200 Message-Id: <83y3jq9q4m.fsf@gnu.org> From: Eli Zaretskii To: 30408@debbugs.gnu.org In-reply-to: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> (message from Paul Eggert on Sat, 17 Feb 2018 17:27:37 -0800) Subject: Re: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 Cc: Emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Paul Eggert > Date: Sat, 17 Feb 2018 17:27:37 -0800 > > Second, although Emacs still reads large integers like 18446744073709551616 as > if they were floating-point, it now signals an error if information is lost in > the process. For example, the number 18446744073709551615 now causes the reader > to signal an error, since it cannot be represented exactly either as a fixnum or > as a floating-point number. If you want inexact representation, you can append > ".0" or "e0" to the integer. I don't think I like this particular effect of the proposed changes. At the very least there should be an easy way of avoiding the error, when the number is not under the control of a Lisp program. E.g., we represent file sizes as floats if the value overflows an Emacs integer, but we definitely don't want to risk signaling errors due to that, e.g. in the likes of ls-lisp.el (and in general any program that calls file-attributes). More generally, why signaling an error by default in this case is a good idea? Emacs Lisp is not used to write software that controls aircraft and spaceships, and probably never will, so why shouldn't we let the programmer request this feature when they need it? That would be similar to behavior of equivalent constructs in C programs, where the inexact exception is AFAIK masked by default. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 18 15:04:33 2018 Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 20:04:33 +0000 Received: from localhost ([127.0.0.1]:50179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enVCL-00039P-5Y for submit@debbugs.gnu.org; Sun, 18 Feb 2018 15:04:33 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enVCI-00039B-Uy for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 15:04:32 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0185A1615B2; Sun, 18 Feb 2018 12:04:25 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JL1c4anzPgyl; Sun, 18 Feb 2018 12:04:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7D16A1615E5; Sun, 18 Feb 2018 12:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8sWl-4VMjwLy; Sun, 18 Feb 2018 12:04:23 -0800 (PST) Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 53CDE1615B2; Sun, 18 Feb 2018 12:04:23 -0800 (PST) Subject: Re: Checking for loss of information on integer conversion To: Eli Zaretskii References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> Date: Sun, 18 Feb 2018 12:04:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83y3jq9q4m.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------2033A6E1E168A9BF2F76BBE8" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org, emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------2033A6E1E168A9BF2F76BBE8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Eli Zaretskii wrote: > Emacs Lisp is not used to write software that controls > aircraft and spaceships Actually, I maintain Emacs Lisp code that controls timestamps used in air= craft=20 and spaceships. I'm not saying that Emacs itself runs the aircraft and=20 spaceships, but it definitely is used to develop software and data used t= here.=20 As luck would have it, I'm currently engaged in an email thread about tim= e=20 transfer between Earth and Mars (yes, this is really a thing and people a= re=20 trying to do it with millisecond precision) that is related to a project = where I=20 regularly use Emacs Lisp. See the thread containing this message: https://mm.icann.org/pipermail/tz/2018-February/026257.html > 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=20 what's in Bug#30408. For example, for this C program: int a =3D 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. It's the latter=20 behavior that causes the sort of problem seen in Bug#30408. When people write a floating-point number they naturally expect it to hav= e some=20 fuzz. But when they write an integer they expect it to be represented exa= ctly,=20 and not to be rounded. Emacs already reports an overflow error for the=20 following code that attempts to use the same mathematical value: (setq c #x10000000000000800) so it's not like it would be a huge change to do something similar for de= cimal=20 integers. When Emacs was originally developed, its integers were typically 28 bits = (not=20 counting sign) and floating-point numbers could typically represent integ= ers=20 exactly up to 53 bits (not counting sign), so the old Emacs behavior was=20 somewhat defensible: although it didn't do bignums, at least it could rep= resent=20 integers nearly twice as wide as fixnums. However, nowadays Emacs integer= s=20 typically have more precision than floating point numbers, and the old Em= acs=20 behavior is more likely to lead to counterintuitive results such as those= =20 described in Bug#30408. On thinking about it in the light of your comments, I suppose it's confus= ing=20 that the proposal used a new signal 'inexact', whereas it should just sig= nal=20 overflow. After all, that's what string_to_number already does for out-of= -range=20 hexadecimal integers. That issue is easily fixed. Revised patch attached. --------------2033A6E1E168A9BF2F76BBE8 Content-Type: text/x-patch; name="0001-Avoid-losing-info-when-converting-integers.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Avoid-losing-info-when-converting-integers.patch" =46rom 49895e55ed7ac41dbf3752ab534cd665ef45ee71 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 18 Feb 2018 11:37:22 -0800 Subject: [PATCH] Avoid losing info when converting integers This fixes some glitches with large integers (Bug#30408). * doc/lispref/numbers.texi (Integer Basics): Say that decimal integers out of fixnum range must be representable exactly as floating-point. * etc/NEWS: Mention this. * src/editfns.c (styled_format): Use %.0f when formatting %d or %i values outside machine integer range, to avoid losing info. Signal an error for %o or %x values that are too large to be formatted, to avoid losing info. * src/lread.c (string_to_number): When converting an integer-format string to floating-point, signal an error if info is lost. --- doc/lispref/numbers.texi | 8 +++-- etc/NEWS | 9 +++++ src/editfns.c | 93 ++++++++++++++++++++----------------------= ------ src/lread.c | 14 ++++++++ 4 files changed, 66 insertions(+), 58 deletions(-) diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index e692ee1cc2..252aafd8fd 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -53,9 +53,11 @@ Integer Basics chapter assume the minimum integer width of 30 bits. @cindex overflow =20 - The Lisp reader reads an integer as a sequence of digits with optional= -initial sign and optional final period. An integer that is out of the -Emacs range is treated as a floating-point number. + The Lisp reader can read an integer as a nonempty sequence of +decimal digits with optional initial sign and optional final period. +A decimal integer that is out of the Emacs range is treated as +floating-point if it can be represented exactly as a floating-point +number. =20 @example 1 ; @r{The integer 1.} diff --git a/etc/NEWS b/etc/NEWS index 8db638e5ed..36cbcf6500 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -248,6 +248,12 @@ as new-style, bind the new variable 'force-new-style= -backquotes' to t. 'cl-struct-define' whose name clashes with a builtin type (e.g., 'integer' or 'hash-table') now signals an error. =20 +** When formatting a floating-point number as an octal or hexadecimal +integer, Emacs now signals an error if the number is too large for the +implementation to format. When reading an integer outside Emacs +fixnum range, Emacs now signals an error if the integer cannot be +represented exactly as a floating-point number. See Bug#30408. + =0C * Lisp Changes in Emacs 27.1 =20 @@ -289,6 +295,9 @@ remote systems, which support this check. If the optional third argument is non-nil, 'make-string' will produce a multibyte string even if its second argument is an ASCII character. =20 +** (format "%d" X) no longer mishandles floating-point X values that +do not fit in a machine integer (Bug#30408). + ** New JSON parsing and serialization functions 'json-serialize', 'json-insert', 'json-parse-string', and 'json-parse-buffer'. These are implemented in C using the Jansson library. diff --git a/src/editfns.c b/src/editfns.c index 96bb271b2d..d26549ddb8 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -4563,32 +4563,30 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) and with pM inserted for integer formats. At most two flags F can be specified at once. */ char convspec[sizeof "%FF.*d" + max (INT_AS_LDBL, pMlen)]; - { - char *f =3D convspec; - *f++ =3D '%'; - /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ - *f =3D '+'; f +=3D plus_flag; - *f =3D ' '; f +=3D space_flag; - *f =3D '#'; f +=3D sharp_flag; - *f++ =3D '.'; - *f++ =3D '*'; - if (float_conversion) - { - if (INT_AS_LDBL) - { - *f =3D 'L'; - f +=3D INTEGERP (arg); - } - } - else if (conversion !=3D 'c') - { - memcpy (f, pMd, pMlen); - f +=3D pMlen; - zero_flag &=3D ! precision_given; - } - *f++ =3D conversion; - *f =3D '\0'; - } + char *f =3D convspec; + *f++ =3D '%'; + /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ + *f =3D '+'; f +=3D plus_flag; + *f =3D ' '; f +=3D space_flag; + *f =3D '#'; f +=3D sharp_flag; + *f++ =3D '.'; + *f++ =3D '*'; + if (float_conversion) + { + if (INT_AS_LDBL) + { + *f =3D 'L'; + f +=3D INTEGERP (arg); + } + } + else if (conversion !=3D 'c') + { + memcpy (f, pMd, pMlen); + f +=3D pMlen; + zero_flag &=3D ! precision_given; + } + *f++ =3D conversion; + *f =3D '\0'; =20 int prec =3D -1; if (precision_given) @@ -4630,29 +4628,18 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) } else if (conversion =3D=3D 'd' || conversion =3D=3D 'i') { - /* For float, maybe we should use "%1.0f" - instead so it also works for values outside - the integer range. */ - printmax_t x; if (INTEGERP (arg)) - x =3D XINT (arg); + { + printmax_t x =3D XINT (arg); + sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); + } else { - double d =3D XFLOAT_DATA (arg); - if (d < 0) - { - x =3D TYPE_MINIMUM (printmax_t); - if (x < d) - x =3D d; - } - else - { - x =3D TYPE_MAXIMUM (printmax_t); - if (d < x) - x =3D d; - } + strcpy (f - pMlen - 1, "f"); + prec =3D 0; + double x =3D XFLOAT_DATA (arg); + sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } - sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } else { @@ -4663,22 +4650,18 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) else { double d =3D XFLOAT_DATA (arg); - if (d < 0) - x =3D 0; - else - { - x =3D TYPE_MAXIMUM (uprintmax_t); - if (d < x) - x =3D d; - } + if (! (0 <=3D d && d < TYPE_MAXIMUM (uprintmax_t))) + xsignal1 (Qoverflow_error, arg); + x =3D d; } sprintf_bytes =3D sprintf (sprintf_buf, convspec, prec, x); } =20 /* Now the length of the formatted item is known, except it omits= padding and excess precision. Deal with excess precision - first. This happens only when the format specifies - ridiculously large precision. */ + first. This happens when the format specifies + ridiculously large precision, or when %d or %i has + nonzero precision and formats a float. */ ptrdiff_t excess_precision =3D precision_given ? precision - prec : 0; ptrdiff_t leading_zeros =3D 0, trailing_zeros =3D 0; diff --git a/src/lread.c b/src/lread.c index d009bd0cd2..9500ed8341 100644 --- a/src/lread.c +++ b/src/lread.c @@ -3794,6 +3794,20 @@ string_to_number (char const *string, int base, bo= ol ignore_trailing) if (! value) value =3D atof (string + signedp); =20 + if (! float_syntax) + { + /* Check that converting the integer-format STRING to a + floating-point number does not lose info. See Bug#30408. */ + char const *bp =3D string + signedp; + while (*bp =3D=3D '0') + bp++; + char checkbuf[DBL_MAX_10_EXP + 2]; + int checkbuflen =3D sprintf (checkbuf, "%.0f", value); + if (! (cp - bp - !!(state & DOT_CHAR) =3D=3D checkbuflen + && memcmp (bp, checkbuf, checkbuflen) =3D=3D 0)) + xsignal1 (Qoverflow_error, build_string (string)); + } + return make_float (negative ? -value : value); } =20 --=20 2.14.3 --------------2033A6E1E168A9BF2F76BBE8-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 18 15:24:41 2018 Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 20:24:41 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Sun, 18 Feb 2018 22:24:34 +0200 Message-Id: <83fu5y9hbx.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> (message from Paul Eggert on Sun, 18 Feb 2018 12:04:20 -0800) Subject: Re: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org, emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 18 16:52:55 2018 Received: (at 30408) by debbugs.gnu.org; 18 Feb 2018 21:52:55 +0000 Received: from localhost ([127.0.0.1]:50243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enWtD-0005kY-CB for submit@debbugs.gnu.org; Sun, 18 Feb 2018 16:52:55 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:43622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enWtC-0005kH-4r for 30408@debbugs.gnu.org; Sun, 18 Feb 2018 16:52:54 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w1ILqVxp025653; Sun, 18 Feb 2018 21:52:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=ACFymioKF+xbB5zKrjIzPe4G2EDfcTzMZfTaWiKyGQ0=; b=MTOIcOmvp9GXPCmufn3HVSjKlKJGu3NdADGwReRImjLln5rlJb6uY0NaPA1IBXrxB3pG YzoCza9mvqkbGj8DbVwgBralwvwmyArqd+43l7xnPBEFPtN14xG6vrnNKOKvMlQgz5rq t2ZJr82gCRQIYnrHlVFQXFvPBVIvN3kdHlggF0aQEprQIPQ7PVBezZwp3110117siWbu xS+Em7DwdTmSBubeHIE6tigK+Pw4lakiKc+kO5SQvP08kLqr4R1/VtQm8kv6vE74Vpbt KUJb5tm8XWd7iRVnoMKh48291pqttqT/T42QgwchwBnAWf1l4E03ARvLNqsEADhiKzlJ xQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2g7g9dg31n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 18 Feb 2018 21:52:30 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w1ILqU79023608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 18 Feb 2018 21:52:30 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w1ILqPb8001737; Sun, 18 Feb 2018 21:52:27 GMT MIME-Version: 1.0 Message-ID: <18580e5c-65c3-4ba2-8ee2-e6b15696422d@default> Date: Sun, 18 Feb 2018 13:52:24 -0800 (PST) From: Drew Adams To: Paul Eggert , Eli Zaretskii Subject: RE: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> In-Reply-To: <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4654.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8808 signatures=668674 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=532 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802180297 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org, emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Do you really need to send this thread to both the bug list and emacs-devel? From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 09 00:00:57 2018 Received: (at 30408) by debbugs.gnu.org; 9 Mar 2018 05:00:57 +0000 Received: from localhost ([127.0.0.1]:51671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euA9J-0005rt-BK for submit@debbugs.gnu.org; Fri, 09 Mar 2018 00:00:57 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euA9H-0005rf-3b for 30408@debbugs.gnu.org; Fri, 09 Mar 2018 00:00:55 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 24B301615E8; Thu, 8 Mar 2018 21:00:49 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 37liVTyrcmfR; Thu, 8 Mar 2018 21:00:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0B16A1615FB; Thu, 8 Mar 2018 21:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EM7unIjLWkPb; Thu, 8 Mar 2018 21:00:47 -0800 (PST) Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D82E11615E8; Thu, 8 Mar 2018 21:00:47 -0800 (PST) Subject: Re: Checking for loss of information on integer conversion To: Eli Zaretskii References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> <83fu5y9hbx.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <66f719bf-2527-a213-5b8e-18044963f30e@cs.ucla.edu> Date: Thu, 8 Mar 2018 21:00:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83fu5y9hbx.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------000F536DECDF2BF7DE93EA82" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------000F536DECDF2BF7DE93EA82 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Since the qualms expressed on this topic had to do with converting strings to integers, I installed into master the noncontroversial part affecting conversion of integers to strings (see attached patch; it also fixes some minor glitches in the previous proposal). I'll think about the string-to-integer conversion a bit more and propose an updated patch for that. --------------000F536DECDF2BF7DE93EA82 Content-Type: text/x-patch; name="0001-Avoid-losing-info-when-formatting-integers.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Avoid-losing-info-when-formatting-integers.patch" >From 80e145fc96765cc0a0f48ae2425294c8c92bce56 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 8 Mar 2018 20:55:55 -0800 Subject: [PATCH] Avoid losing info when formatting integers * doc/lispref/numbers.texi (Integer Basics): Clarify that out-of-range integers are treated as floating point only when the integers are decimal. * etc/NEWS: Mention changes. * src/editfns.c (styled_format): Use %.0f when formatting %d or %i values outside machine integer range, to avoid losing info. Signal an error for %o or %x values that are too large to be formatted, to avoid losing info. --- doc/lispref/numbers.texi | 5 ++- etc/NEWS | 7 ++++ src/editfns.c | 96 +++++++++++++++++++++--------------------------- 3 files changed, 51 insertions(+), 57 deletions(-) diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index e692ee1..f1180cf 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -53,8 +53,9 @@ Integer Basics chapter assume the minimum integer width of 30 bits. @cindex overflow - The Lisp reader reads an integer as a sequence of digits with optional -initial sign and optional final period. An integer that is out of the + The Lisp reader reads an integer as a nonempty sequence +of decimal digits with optional initial sign and optional +final period. A decimal integer that is out of the Emacs range is treated as a floating-point number. @example diff --git a/etc/NEWS b/etc/NEWS index 07f6d04..14926ba 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -302,6 +302,10 @@ as new-style, bind the new variable 'force-new-style-backquotes' to t. 'cl-struct-define' whose name clashes with a builtin type (e.g., 'integer' or 'hash-table') now signals an error. +** When formatting a floating-point number as an octal or hexadecimal +integer, Emacs now signals an error if the number is too large for the +implementation to format (Bug#30408). + * Lisp Changes in Emacs 27.1 @@ -343,6 +347,9 @@ remote systems, which support this check. If the optional third argument is non-nil, 'make-string' will produce a multibyte string even if its second argument is an ASCII character. +** (format "%d" X) no longer mishandles a floating-point number X that +does not fit in a machine integer (Bug#30408). + ** New JSON parsing and serialization functions 'json-serialize', 'json-insert', 'json-parse-string', and 'json-parse-buffer'. These are implemented in C using the Jansson library. diff --git a/src/editfns.c b/src/editfns.c index 96bb271..3a34dd0 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -4563,32 +4563,30 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool message) and with pM inserted for integer formats. At most two flags F can be specified at once. */ char convspec[sizeof "%FF.*d" + max (INT_AS_LDBL, pMlen)]; - { - char *f = convspec; - *f++ = '%'; - /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ - *f = '+'; f += plus_flag; - *f = ' '; f += space_flag; - *f = '#'; f += sharp_flag; - *f++ = '.'; - *f++ = '*'; - if (float_conversion) - { - if (INT_AS_LDBL) - { - *f = 'L'; - f += INTEGERP (arg); - } - } - else if (conversion != 'c') - { - memcpy (f, pMd, pMlen); - f += pMlen; - zero_flag &= ! precision_given; - } - *f++ = conversion; - *f = '\0'; - } + char *f = convspec; + *f++ = '%'; + /* MINUS_FLAG and ZERO_FLAG are dealt with later. */ + *f = '+'; f += plus_flag; + *f = ' '; f += space_flag; + *f = '#'; f += sharp_flag; + *f++ = '.'; + *f++ = '*'; + if (float_conversion) + { + if (INT_AS_LDBL) + { + *f = 'L'; + f += INTEGERP (arg); + } + } + else if (conversion != 'c') + { + memcpy (f, pMd, pMlen); + f += pMlen; + zero_flag &= ! precision_given; + } + *f++ = conversion; + *f = '\0'; int prec = -1; if (precision_given) @@ -4630,29 +4628,20 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool message) } else if (conversion == 'd' || conversion == 'i') { - /* For float, maybe we should use "%1.0f" - instead so it also works for values outside - the integer range. */ - printmax_t x; if (INTEGERP (arg)) - x = XINT (arg); + { + printmax_t x = XINT (arg); + sprintf_bytes = sprintf (sprintf_buf, convspec, prec, x); + } else { - double d = XFLOAT_DATA (arg); - if (d < 0) - { - x = TYPE_MINIMUM (printmax_t); - if (x < d) - x = d; - } - else - { - x = TYPE_MAXIMUM (printmax_t); - if (d < x) - x = d; - } + strcpy (f - pMlen - 1, "f"); + double x = XFLOAT_DATA (arg); + sprintf_bytes = sprintf (sprintf_buf, convspec, 0, x); + char c0 = sprintf_buf[0]; + bool signedp = ! ('0' <= c0 && c0 <= '9'); + prec = min (precision, sprintf_bytes - signedp); } - sprintf_bytes = sprintf (sprintf_buf, convspec, prec, x); } else { @@ -4663,22 +4652,19 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool message) else { double d = XFLOAT_DATA (arg); - if (d < 0) - x = 0; - else - { - x = TYPE_MAXIMUM (uprintmax_t); - if (d < x) - x = d; - } + double uprintmax = TYPE_MAXIMUM (uprintmax_t); + if (! (0 <= d && d < uprintmax + 1)) + xsignal1 (Qoverflow_error, arg); + x = d; } sprintf_bytes = sprintf (sprintf_buf, convspec, prec, x); } /* Now the length of the formatted item is known, except it omits padding and excess precision. Deal with excess precision - first. This happens only when the format specifies - ridiculously large precision. */ + first. This happens when the format specifies ridiculously + large precision, or when %d or %i formats a float that would + ordinarily need fewer digits than a specified precision. */ ptrdiff_t excess_precision = precision_given ? precision - prec : 0; ptrdiff_t leading_zeros = 0, trailing_zeros = 0; -- 2.7.4 --------------000F536DECDF2BF7DE93EA82-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 09 03:23:12 2018 Received: (at 30408) by debbugs.gnu.org; 9 Mar 2018 08:23:12 +0000 Received: from localhost ([127.0.0.1]:51710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euDJ1-0002wS-Os for submit@debbugs.gnu.org; Fri, 09 Mar 2018 03:23:11 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euDJ0-0002wE-4h for 30408@debbugs.gnu.org; Fri, 09 Mar 2018 03:23:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euDIq-000538-VO for 30408@debbugs.gnu.org; Fri, 09 Mar 2018 03:23:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euDIq-000530-RH; Fri, 09 Mar 2018 03:23:00 -0500 Received: from [176.228.60.248] (port=4566 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1euDIq-00018N-4g; Fri, 09 Mar 2018 03:23:00 -0500 Date: Fri, 09 Mar 2018 10:22:58 +0200 Message-Id: <83o9jxody5.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <66f719bf-2527-a213-5b8e-18044963f30e@cs.ucla.edu> (message from Paul Eggert on Thu, 8 Mar 2018 21:00:42 -0800) Subject: Re: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> <83fu5y9hbx.fsf@gnu.org> <66f719bf-2527-a213-5b8e-18044963f30e@cs.ucla.edu> 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 30408@debbugs.gnu.org > From: Paul Eggert > Date: Thu, 8 Mar 2018 21:00:42 -0800 > > Since the qualms expressed on this topic had to do with converting strings to > integers, I installed into master the noncontroversial part affecting conversion > of integers to strings (see attached patch; it also fixes some minor glitches in > the previous proposal). I'll think about the string-to-integer conversion a bit > more and propose an updated patch for that. Thanks. May I suggest to add a couple of tests for this feature? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 21 15:13:58 2018 Received: (at 30408) by debbugs.gnu.org; 21 Mar 2018 19:13:58 +0000 Received: from localhost ([127.0.0.1]:46241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjBO-0007XC-4G for submit@debbugs.gnu.org; Wed, 21 Mar 2018 15:13:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjBM-0007Wz-Rs for 30408@debbugs.gnu.org; Wed, 21 Mar 2018 15:13:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BEF2B1616ED; Wed, 21 Mar 2018 12:13:50 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UIL0ptLzjJoL; Wed, 21 Mar 2018 12:13:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EFA3B1616F4; Wed, 21 Mar 2018 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3MPaQZomcQTx; Wed, 21 Mar 2018 12:13:49 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D68361616ED; Wed, 21 Mar 2018 12:13:49 -0700 (PDT) Subject: Re: Checking for loss of information on integer conversion To: Eli Zaretskii References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> <83fu5y9hbx.fsf@gnu.org> <66f719bf-2527-a213-5b8e-18044963f30e@cs.ucla.edu> <83o9jxody5.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <9186c001-13d8-6d8d-9298-ce4615e1324f@cs.ucla.edu> Date: Wed, 21 Mar 2018 12:13:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83o9jxody5.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------5C6A4D4459BA98196AD7685E" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------5C6A4D4459BA98196AD7685E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 03/09/2018 12:22 AM, Eli Zaretskii wrote: > May I suggest to add a couple of tests for this feature? Sure, I installed the attached. --------------5C6A4D4459BA98196AD7685E Content-Type: text/x-patch; name="0001-Add-tests-for-Bug-30408.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Add-tests-for-Bug-30408.patch" >From 84dbd740c440b4c048f675486af7292cdf251c9f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 21 Mar 2018 12:10:11 -0700 Subject: [PATCH] Add tests for Bug#30408 * test/src/editfns-tests.el (format-%d-large-float) (format-%x-large-float, format-%o-invalid-float): New tests. --- test/src/editfns-tests.el | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el index 69ea6f5cc8..6e1f730166 100644 --- a/test/src/editfns-tests.el +++ b/test/src/editfns-tests.el @@ -142,6 +142,27 @@ transpose-test-get-byte-positions (should (string-equal (format "%#05X" #x10) "0X010")) (should (string-equal (format "%#04x" 0) "0000"))) +;;; Test Bug#30408. +(ert-deftest format-%d-large-float () + (should (string-equal (format "%d" 18446744073709551616.0) + "18446744073709551616")) + (should (string-equal (format "%d" -18446744073709551616.0) + "-18446744073709551616"))) + +;;; Another test for Bug#30408. +;;; Perhaps Emacs will be improved someday to return the correct +;;; answer for positive numbers instead of overflowing; in +;;; that case this test will need to be changed. In the meantime make +;;; sure Emacs is reporting the overflow correctly. +(ert-deftest format-%x-large-float () + (should-error (format "%x" 18446744073709551616.0) + :type 'overflow-error)) + +;;; Another test for Bug#30408. +(ert-deftest format-%o-invalid-float () + (should-error (format "%o" -1e-37) + :type 'overflow-error)) + ;;; Check format-time-string with various TZ settings. ;;; Use only POSIX-compatible TZ values, since the tests should work ;;; even if tzdb is not in use. -- 2.14.3 --------------5C6A4D4459BA98196AD7685E-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 21 15:29:44 2018 Received: (at 30408) by debbugs.gnu.org; 21 Mar 2018 19:29:44 +0000 Received: from localhost ([127.0.0.1]:46250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjQd-0007uf-Pu for submit@debbugs.gnu.org; Wed, 21 Mar 2018 15:29:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyjQc-0007uS-G4 for 30408@debbugs.gnu.org; Wed, 21 Mar 2018 15:29:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyjQT-0001HR-BI for 30408@debbugs.gnu.org; Wed, 21 Mar 2018 15:29:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyjQT-0001HE-80; Wed, 21 Mar 2018 15:29:33 -0400 Received: from [176.228.60.248] (port=3416 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eyjQS-0005eU-OY; Wed, 21 Mar 2018 15:29:33 -0400 Date: Wed, 21 Mar 2018 21:29:30 +0200 Message-Id: <83efkdjkh1.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <9186c001-13d8-6d8d-9298-ce4615e1324f@cs.ucla.edu> (message from Paul Eggert on Wed, 21 Mar 2018 12:13:49 -0700) Subject: Re: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <74ac7b77-a756-95a9-b490-6952cf106f21@cs.ucla.edu> <83fu5y9hbx.fsf@gnu.org> <66f719bf-2527-a213-5b8e-18044963f30e@cs.ucla.edu> <83o9jxody5.fsf@gnu.org> <9186c001-13d8-6d8d-9298-ce4615e1324f@cs.ucla.edu> 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 30408@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 21 Mar 2018 12:13:49 -0700 > > On 03/09/2018 12:22 AM, Eli Zaretskii wrote: > > May I suggest to add a couple of tests for this feature? > > Sure, I installed the attached. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 27 19:19:33 2018 Received: (at 30408) by debbugs.gnu.org; 27 Mar 2018 23:19:33 +0000 Received: from localhost ([127.0.0.1]:56369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0xsK-0007NA-Ff for submit@debbugs.gnu.org; Tue, 27 Mar 2018 19:19:32 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0xsH-0007Mw-Nz for 30408@debbugs.gnu.org; Tue, 27 Mar 2018 19:19:30 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9DF84161446; Tue, 27 Mar 2018 16:19:23 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LVCKYMWmqoys; Tue, 27 Mar 2018 16:19:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3ADFB1614F9; Tue, 27 Mar 2018 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n-3JNygiUATs; Tue, 27 Mar 2018 16:19:22 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1934D161446; Tue, 27 Mar 2018 16:19:22 -0700 (PDT) Subject: Re: Checking for loss of information on integer conversion To: Eli Zaretskii , 30408@debbugs.gnu.org References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Tue, 27 Mar 2018 16:19:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83y3jq9q4m.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------C8997759E81B0890A121F27F" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------C8997759E81B0890A121F27F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here's a patch that I hope addresses the main problem. The basic idea is to avoid the confusion exemplified in Bug#30408 by changing Emacs so that it ordinarily signals an error if it reads a program that contains an integer literal that is out of fixnum range. However, if the out-of-range literal is followed by '.' then Emacs continues to silently convert it to floating-point; this is intended as an escape hatch for any programs that need the old behavior (I expect this'll be rare). Thus, on 32-bit Emacs, plain '536870912' in a program causes Emacs to signal an overflow while loading the program, whereas '536870912.' is treated as a floating-point number as before. (On 64-bit Emacs, the same two literals are both integers, as before.) Unlike my previous proposal, this patch does not affect the behavior of string-to-integer. As I understand it, that was a primary source of qualms about the previous proposal. I've tested this on both 32- and 64-bit Emacs on master. This patch has helped me to find a couple of integer portability bugs which I already fixed on master. --------------C8997759E81B0890A121F27F Content-Type: text/x-patch; name="0001-Lisp-reader-now-checks-for-integer-overflow.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Lisp-reader-now-checks-for-integer-overflow.patch" >From 94b7a1a171de3113cd5250315dee7bdef5f51890 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 27 Mar 2018 15:48:47 -0700 Subject: [PATCH] Lisp reader now checks for integer overflow * doc/lispref/numbers.texi (Integer Basics), etc/NEWS: Document this. * src/lisp.h (S2N_IGNORE_TRAILING, S2N_OVERFLOW_TO_FLOAT): New constants. * src/lread.c (string_to_number): Change trailing bool arg to integer argument with flags, to support S2N_OVERFLOW_TO_FLOAT. All uses changed. * test/src/editfns-tests.el (read-large-integer): New test. --- doc/lispref/numbers.texi | 14 ++++++++++---- etc/NEWS | 7 +++++++ src/data.c | 9 ++++----- src/lisp.h | 3 ++- src/lread.c | 35 ++++++++++++++++++++--------------- src/process.c | 2 +- test/src/editfns-tests.el | 22 ++++++++++++++++++---- 7 files changed, 62 insertions(+), 30 deletions(-) diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index c2cb6651d4..2fed2b642f 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -55,16 +55,13 @@ Integer Basics The Lisp reader reads an integer as a nonempty sequence of decimal digits with optional initial sign and optional -final period. A decimal integer that is out of the -Emacs range is treated as a floating-point number. +final period. @example 1 ; @r{The integer 1.} 1. ; @r{The integer 1.} +1 ; @r{Also the integer 1.} -1 ; @r{The integer @minus{}1.} - 9000000000000000000 - ; @r{The floating-point number 9e18.} 0 ; @r{The integer 0.} -0 ; @r{The integer 0.} @end example @@ -94,6 +91,15 @@ Integer Basics #24r1k @result{} 44 @end example + If an integer is outside the Emacs range, the Lisp reader ordinarily +signals an overflow. However, if a too-large plain integer ends in a +period, the Lisp reader treats it as a floating-point number instead. +This lets an Emacs Lisp program specify a large integer that is +quietly approximated by a floating-point number on machines with +limited word width. For example, @samp{536870912.} is a +floating-point number if Emacs integers are only 30 bits wide and is +an integer otherwise. + To understand how various functions work on integers, especially the bitwise operators (@pxref{Bitwise Operations}), it is often helpful to view the numbers in their binary form. diff --git a/etc/NEWS b/etc/NEWS index fd1d04b8a0..cb74f512cc 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -349,6 +349,13 @@ as new-style, bind the new variable 'force-new-style-backquotes' to t. integer, Emacs now signals an error if the number is too large for the implementation to format (Bug#30408). ++++ +** The Lisp reader now signals an overflow for plain decimal integers +that do not end in '.' and are outside Emacs range. Formerly the Lisp +reader silently converted them to floating-point numbers, and signaled +overflow only for integers with a radix that are outside machine range +(Bug#30408). + --- ** Some functions and variables obsolete since Emacs 22 have been removed: archive-mouse-extract, assoc-ignore-case, assoc-ignore-representation, diff --git a/src/data.c b/src/data.c index a7fab1ef58..6f23a26757 100644 --- a/src/data.c +++ b/src/data.c @@ -2716,9 +2716,7 @@ present, base 10 is used. BASE must be between 2 and 16 (inclusive). If the base used is not 10, STRING is always parsed as an integer. */) (register Lisp_Object string, Lisp_Object base) { - register char *p; - register int b; - Lisp_Object val; + int b; CHECK_STRING (string); @@ -2732,11 +2730,12 @@ If the base used is not 10, STRING is always parsed as an integer. */) b = XINT (base); } - p = SSDATA (string); + char *p = SSDATA (string); while (*p == ' ' || *p == '\t') p++; - val = string_to_number (p, b, true); + int flags = S2N_IGNORE_TRAILING | S2N_OVERFLOW_TO_FLOAT; + Lisp_Object val = string_to_number (p, b, flags); return NILP (val) ? make_number (0) : val; } diff --git a/src/lisp.h b/src/lisp.h index f0c0c5a14a..b931d23bf3 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3899,7 +3899,8 @@ LOADHIST_ATTACH (Lisp_Object x) } extern int openp (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object *, Lisp_Object, bool); -extern Lisp_Object string_to_number (char const *, int, bool); +enum { S2N_IGNORE_TRAILING = 1, S2N_OVERFLOW_TO_FLOAT = 2 }; +extern Lisp_Object string_to_number (char const *, int, int); extern void map_obarray (Lisp_Object, void (*) (Lisp_Object, Lisp_Object), Lisp_Object); extern void dir_warning (const char *, Lisp_Object); diff --git a/src/lread.c b/src/lread.c index 381f9cf20c..a774524ee4 100644 --- a/src/lread.c +++ b/src/lread.c @@ -2339,7 +2339,7 @@ character_name_to_code (char const *name, ptrdiff_t name_len) monstrosities like "U+-0000". */ Lisp_Object code = (name[0] == 'U' && name[1] == '+' - ? string_to_number (name + 1, 16, false) + ? string_to_number (name + 1, 16, 0) : call2 (Qchar_from_name, make_unibyte_string (name, name_len), Qt)); if (! RANGED_INTEGERP (0, code, MAX_UNICODE_CHAR) @@ -2693,7 +2693,7 @@ read_integer (Lisp_Object readcharfun, EMACS_INT radix) invalid_syntax (buf); } - return string_to_number (buf, radix, false); + return string_to_number (buf, radix, 0); } @@ -3502,7 +3502,7 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list) if (!quoted && !uninterned_symbol) { - Lisp_Object result = string_to_number (read_buffer, 10, false); + Lisp_Object result = string_to_number (read_buffer, 10, 0); if (! NILP (result)) return unbind_to (count, result); } @@ -3667,16 +3667,17 @@ substitute_in_interval (INTERVAL interval, void *arg) } -/* Convert STRING to a number, assuming base BASE. Return a fixnum if - STRING has integer syntax and fits in a fixnum, else return the - nearest float if STRING has either floating point or integer syntax - and BASE is 10, else return nil. If IGNORE_TRAILING, consider just - the longest prefix of STRING that has valid floating point syntax. - Signal an overflow if BASE is not 10 and the number has integer - syntax but does not fit. */ +/* Convert STRING to a number, assuming base BASE. When STRING has + floating point syntax and BASE is 10, return a nearest float. When + STRING has integer syntax, return a fixnum if the integer fits, and + signal an overflow otherwise (unless BASE is 10 and STRING ends in + period or FLAGS & S2N_OVERFLOW_TO_FLOAT is nonzero; in this case, + return a nearest float instead). Otherwise, return nil. If FLAGS + & S2N_IGNORE_TRAILING is nonzero, consider just the longest prefix + of STRING that has valid syntax. */ Lisp_Object -string_to_number (char const *string, int base, bool ignore_trailing) +string_to_number (char const *string, int base, int flags) { char const *cp = string; bool float_syntax = 0; @@ -3759,9 +3760,10 @@ string_to_number (char const *string, int base, bool ignore_trailing) || (state & ~INTOVERFLOW) == (LEAD_INT|E_EXP)); } - /* Return nil if the number uses invalid syntax. If IGNORE_TRAILING, accept - any prefix that matches. Otherwise, the entire string must match. */ - if (! (ignore_trailing + /* Return nil if the number uses invalid syntax. If FLAGS & + S2N_IGNORE_TRAILING, accept any prefix that matches. Otherwise, + the entire string must match. */ + if (! (flags & S2N_IGNORE_TRAILING ? ((state & LEAD_INT) != 0 || float_syntax) : (!*cp && ((state & ~(INTOVERFLOW | DOT_CHAR)) == LEAD_INT || float_syntax)))) @@ -3776,7 +3778,7 @@ string_to_number (char const *string, int base, bool ignore_trailing) /* Unfortunately there's no simple and accurate way to convert non-base-10 numbers that are out of C-language range. */ if (base != 10) - xsignal1 (Qoverflow_error, build_string (string)); + flags = 0; } else if (n <= (negative ? -MOST_NEGATIVE_FIXNUM : MOST_POSITIVE_FIXNUM)) { @@ -3785,6 +3787,9 @@ string_to_number (char const *string, int base, bool ignore_trailing) } else value = n; + + if (! (state & DOT_CHAR) && ! (flags & S2N_OVERFLOW_TO_FLOAT)) + xsignal1 (Qoverflow_error, build_string (string)); } /* Either the number uses float syntax, or it does not fit into a fixnum. diff --git a/src/process.c b/src/process.c index 2aaa238f60..ed2cab7b51 100644 --- a/src/process.c +++ b/src/process.c @@ -6842,7 +6842,7 @@ SIGCODE may be an integer, or a symbol whose name is a signal name. */) { Lisp_Object tem = Fget_process (process); if (NILP (tem)) - tem = string_to_number (SSDATA (process), 10, true); + tem = string_to_number (SSDATA (process), 10, S2N_OVERFLOW_TO_FLOAT); process = tem; } else if (!NUMBERP (process)) diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el index 6e1f730166..442ad08937 100644 --- a/test/src/editfns-tests.el +++ b/test/src/editfns-tests.el @@ -142,27 +142,41 @@ transpose-test-get-byte-positions (should (string-equal (format "%#05X" #x10) "0X010")) (should (string-equal (format "%#04x" 0) "0000"))) -;;; Test Bug#30408. + +;;; Tests for Bug#30408. + (ert-deftest format-%d-large-float () (should (string-equal (format "%d" 18446744073709551616.0) "18446744073709551616")) (should (string-equal (format "%d" -18446744073709551616.0) "-18446744073709551616"))) -;;; Another test for Bug#30408. ;;; Perhaps Emacs will be improved someday to return the correct ;;; answer for positive numbers instead of overflowing; in -;;; that case this test will need to be changed. In the meantime make +;;; that case these tests will need to be changed. In the meantime make ;;; sure Emacs is reporting the overflow correctly. (ert-deftest format-%x-large-float () (should-error (format "%x" 18446744073709551616.0) :type 'overflow-error)) +(ert-deftest read-large-integer () + (should-error (read (format "%d0" most-negative-fixnum)) + :type 'overflow-error) + (should-error (read (format "%+d" (* -8.0 most-negative-fixnum))) + :type 'overflow-error) + (should-error (read (substring (format "%d" most-negative-fixnum) 1)) + :type 'overflow-error) + (should-error (read (format "#x%x" most-negative-fixnum)) + :type 'overflow-error) + (should-error (read (format "#o%o" most-negative-fixnum)) + :type 'overflow-error) + (should-error (read (format "#32rG%x" most-positive-fixnum)) + :type 'overflow-error)) -;;; Another test for Bug#30408. (ert-deftest format-%o-invalid-float () (should-error (format "%o" -1e-37) :type 'overflow-error)) + ;;; Check format-time-string with various TZ settings. ;;; Use only POSIX-compatible TZ values, since the tests should work ;;; even if tzdb is not in use. -- 2.14.3 --------------C8997759E81B0890A121F27F-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 29 07:11:38 2018 Received: (at 30408) by debbugs.gnu.org; 29 Mar 2018 11:11:38 +0000 Received: from localhost ([127.0.0.1]:58015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1VT0-0004vy-Hr for submit@debbugs.gnu.org; Thu, 29 Mar 2018 07:11:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1VSy-0004vl-Qn for 30408@debbugs.gnu.org; Thu, 29 Mar 2018 07:11:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1VSo-000492-Nq for 30408@debbugs.gnu.org; Thu, 29 Mar 2018 07:11:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1VSo-00048w-KT; Thu, 29 Mar 2018 07:11:26 -0400 Received: from [176.228.60.248] (port=2102 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f1VSn-0007jN-Fi; Thu, 29 Mar 2018 07:11:26 -0400 Date: Thu, 29 Mar 2018 14:11:10 +0300 Message-Id: <83605fdtm9.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Tue, 27 Mar 2018 16:19:21 -0700) Subject: Re: Checking for loss of information on integer conversion References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 Cc: 30408@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Paul Eggert > Date: Tue, 27 Mar 2018 16:19:21 -0700 > > Here's a patch that I hope addresses the main problem. The basic idea is > to avoid the confusion exemplified in Bug#30408 by changing Emacs so > that it ordinarily signals an error if it reads a program that contains > an integer literal that is out of fixnum range. However, if the > out-of-range literal is followed by '.' then Emacs continues to silently > convert it to floating-point; this is intended as an escape hatch for > any programs that need the old behavior (I expect this'll be rare). I'd suggest, for a good measure, to have a variable which would force the conversion to floats, avoiding an error even without the trailing period. We can later remove that variable, or make it a no-op, if the danger of breaking existing code turns out low or non-existent. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 29 14:09:56 2018 Received: (at 30408-done) by debbugs.gnu.org; 29 Mar 2018 18:09:56 +0000 Received: from localhost ([127.0.0.1]:58977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1bzn-0000Tz-QB for submit@debbugs.gnu.org; Thu, 29 Mar 2018 14:09:56 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1bzl-0000Tl-In for 30408-done@debbugs.gnu.org; Thu, 29 Mar 2018 14:09:54 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E5832160AD0; Thu, 29 Mar 2018 11:09:47 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PkRft8wklFtm; Thu, 29 Mar 2018 11:09:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 379BB1616D4; Thu, 29 Mar 2018 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wuVvZSSGhs4u; Thu, 29 Mar 2018 11:09:46 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1DEA8160AD0; Thu, 29 Mar 2018 11:09:46 -0700 (PDT) Subject: Re: Checking for loss of information on integer conversion To: Eli Zaretskii References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <83y3jq9q4m.fsf@gnu.org> <83605fdtm9.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Thu, 29 Mar 2018 11:09:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83605fdtm9.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------0A202BB77F423E21318F69EF" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 30408-done Cc: 30408-done@debbugs.gnu.org, David Sitsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------0A202BB77F423E21318F69EF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 03/29/2018 04:11 AM, Eli Zaretskii wrote: > I'd suggest, for a good measure, to have a variable which would force > the conversion to floats, avoiding an error even without the trailing > period. We can later remove that variable, or make it a no-op, if the > danger of breaking existing code turns out low or non-existent. OK, I did that, by installing the attached into master, after installing the proposed patch. As a result, unless the user sets the new variable read-integer-overflow-as-float, the Lisp reader now rejects the program (format "%x" 2738188573457603759) by signaling an overflow error. As this was the basis of the original bug report, I'm marking the bug as done. --------------0A202BB77F423E21318F69EF Content-Type: text/x-patch; name="0001-New-experimental-variable-read-integer-overflow-as-f.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-New-experimental-variable-read-integer-overflow-as-f.pa"; filename*1="tch" >From c213f465ba8038ce93314b96fd53ec3e35d34609 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 29 Mar 2018 11:01:38 -0700 Subject: [PATCH] New experimental variable read-integer-overflow-as-float. Following a suggestion by Eli Zaretskii (Bug#30408#46). * etc/NEWS: Mention it. * src/lread.c (syms_of_lread): Add it. (read1): Treat out-of-range integers as floats if read-integer-overflow-as-float is non-nil. --- etc/NEWS | 6 ++++-- src/lread.c | 11 ++++++++++- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 9161f2bd32..9dddc90213 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -356,8 +356,10 @@ implementation to format (Bug#30408). ** The Lisp reader now signals an overflow for plain decimal integers that do not end in '.' and are outside Emacs range. Formerly the Lisp reader silently converted them to floating-point numbers, and signaled -overflow only for integers with a radix that are outside machine range -(Bug#30408). +overflow only for integers with a radix that are outside machine range. +To get the old behavior, set the new, experimental variable +read-integer-overflow-as-float to t and please email +30408@debbugs.gnu.org if you need that. (Bug#30408). --- ** Some functions and variables obsolete since Emacs 22 have been removed: diff --git a/src/lread.c b/src/lread.c index a774524ee4..8fb61f5633 100644 --- a/src/lread.c +++ b/src/lread.c @@ -3502,7 +3502,9 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list) if (!quoted && !uninterned_symbol) { - Lisp_Object result = string_to_number (read_buffer, 10, 0); + int flags = (read_integer_overflow_as_float + ? S2N_OVERFLOW_TO_FLOAT : 0); + Lisp_Object result = string_to_number (read_buffer, 10, flags); if (! NILP (result)) return unbind_to (count, result); } @@ -4830,6 +4832,13 @@ were read in. */); doc: /* Non-nil means read recursive structures using #N= and #N# syntax. */); Vread_circle = Qt; + DEFVAR_BOOL ("read-integer-overflow-as-float", + read_integer_overflow_as_float, + doc: /* Non-nil means `read' quietly treats an out-of-range integer as floating point. +Nil (the default) means signal an overflow unless the integer ends in `.'. +This variable is experimental; email 30408@debbugs.gnu.org if you need it. */); + read_integer_overflow_as_float = false; + DEFVAR_LISP ("load-path", Vload_path, doc: /* List of directories to search for files to load. Each element is a string (directory file name) or nil (meaning -- 2.14.3 --------------0A202BB77F423E21318F69EF-- From unknown Sun Jun 22 03:56:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 27 Apr 2018 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 02:58:21 2018 Received: (at control) by debbugs.gnu.org; 6 May 2018 06:58:21 +0000 Received: from localhost ([127.0.0.1]:50953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fFDcj-0008L7-Ip for submit@debbugs.gnu.org; Sun, 06 May 2018 02:58:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fFDch-0008Kv-U7 for control@debbugs.gnu.org; Sun, 06 May 2018 02:58:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFDcZ-00078o-JO for control@debbugs.gnu.org; Sun, 06 May 2018 02:58:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFDcZ-00078h-Fa for control@debbugs.gnu.org; Sun, 06 May 2018 02:58:11 -0400 Received: from [78.192.157.63] (port=38118 helo=bzg.fr) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1fFDcY-00021u-MD for control@debbugs.gnu.org; Sun, 06 May 2018 02:58:11 -0400 Received: by bzg.fr (Postfix, from userid 1000) id 996E93809C4; Sun, 6 May 2018 08:58:07 +0200 (CEST) From: Bastien To: control@debbugs.gnu.org Subject: unarchive 30408 Date: Sun, 06 May 2018 08:58:07 +0200 Message-ID: <87sh755kzk.fsf@bzg.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) unarchive 30408 -- Bastien From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 05:57:22 2018 Received: (at 30408) by debbugs.gnu.org; 6 May 2018 09:57:22 +0000 Received: from localhost ([127.0.0.1]:50996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fFGPy-0006I5-7i for submit@debbugs.gnu.org; Sun, 06 May 2018 05:57:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fFGPx-0006Hv-0H for 30408@debbugs.gnu.org; Sun, 06 May 2018 05:57:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFGPo-0000ii-Lj for 30408@debbugs.gnu.org; Sun, 06 May 2018 05:57:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFGPo-0000ic-IK for 30408@debbugs.gnu.org; Sun, 06 May 2018 05:57:12 -0400 Received: from [78.192.157.63] (port=39054 helo=bzg.fr) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1fFGPo-0002Rq-7r for 30408@debbugs.gnu.org; Sun, 06 May 2018 05:57:12 -0400 Received: by bzg.fr (Postfix, from userid 1000) id 03A7A3809C4; Sun, 6 May 2018 11:57:09 +0200 (CEST) Resent-To: 30408@debbugs.gnu.org Resent-From: Bastien Resent-Date: Sun, 06 May 2018 11:57:09 +0200 Resent-Message-ID: <874ljl5cp6.fsf@bzg.fr> From: Bastien To: 30408@debbugs.gnu.org Subject: More context in `read-integer-overflow-as-float'? Date: Sun, 06 May 2018 08:29:10 +0200 Message-ID: <87wowh5mbt.fsf@bzg.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 30408 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) As suggested in `read-integer-overflow-as-float' docstring: Non-nil means =E2=80=98read=E2=80=99 quietly treats an out-of-range integ= er as floating point. Nil (the default) means signal an overflow unless the integer ends in =E2=80=98.=E2=80=99. This variable is experimental; = email 30408@debbugs.gnu.org if you need it. (Note that the last sentence is a bit ambiguous: does "if you need it" refer to sending an email or to the variable?) Apparently I need (setq read-integer-overflow-as-float t) since I've been hit by bugs here. But what are the consequences of setting this to `t', aside from silencing a few errors? What is the usefulness of not setting it to `t'? What is the experiment about? Can I get rid of this setting when the experiment is over? Since `read-integer-overflow-as-float' is the entry point for those who are not aware of the experiment, some guidance in the docstring might be useful. Thanks, --=20 Bastien From unknown Sun Jun 22 03:56:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 03 Jun 2018 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator