From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Checking for loss of information on integer conversion Date: Sun, 18 Feb 2018 18:22:52 -0800 Organization: UCLA Computer Science Department Message-ID: References: <7432641a-cedc-942c-d75c-0320fce5ba39@cs.ucla.edu> <87woza7wwi.fsf@trurl.irif.fr> <87sh9x97yz.fsf@trurl.irif.fr> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519006885 7850 195.159.176.226 (19 Feb 2018 02:21:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Feb 2018 02:21:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 19 03:21:21 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enb4k-0000wf-S5 for ged-emacs-devel@m.gmane.org; Mon, 19 Feb 2018 03:21:06 +0100 Original-Received: from localhost ([::1]:47219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enb6j-0004nX-RE for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 21:23:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enb6b-0004nQ-Qu for emacs-devel@gnu.org; Sun, 18 Feb 2018 21:23:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enb6Y-0001Ox-NH for emacs-devel@gnu.org; Sun, 18 Feb 2018 21:23:01 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35224) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1enb6Y-0001Oh-Gj for emacs-devel@gnu.org; Sun, 18 Feb 2018 21:22:58 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 400831615B2; Sun, 18 Feb 2018 18:22:56 -0800 (PST) Original-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 0jSApDSxYUjl; Sun, 18 Feb 2018 18:22:55 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8CFAC1615E5; Sun, 18 Feb 2018 18:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-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 qf1qIbrpn0Vn; Sun, 18 Feb 2018 18:22:55 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6A86A1615B2; Sun, 18 Feb 2018 18:22:55 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222890 Archived-At: Stefan Monnier wrote: > I don't think adding actual bignums via (say) libgmp would be > significantly harder than adding such "small bignums. Although I suspect libgmp would be considerably more of a pain than small bignums (e.g., due to the memory-allocation hassle) I agree we should spend our limited development time on true bignums rather than on small ones. Emacs already links to libgmp so this shouldn't introduce any new dependencies. However, this is all a matter for a later day. > On 64bit systems (and 32bit systems built with wide-ints), > I don't see such a clear need to convert a large integer into a float, > so on those systems I think it's OK to just signal an error. I'll take a look into doing things that way, and into following Eli's suggestion to make it configurable.