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: Making 'eq' == 'eql' in bignum branch Date: Sat, 25 Aug 2018 16:27:20 -0700 Organization: UCLA Computer Science Department Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <49d8ba62-c9a5-9203-d882-8e900b441ff3@cs.ucla.edu> <8e0320d9-e0d0-2b57-57cc-2df4399f133c@cs.ucla.edu> <87lgaio7xd.fsf@tromey.com> <877em1cb0i.fsf@tromey.com> <765767b2-d2e5-a9a6-f724-d58ecf4847bb@cs.ucla.edu> <76081b5d-8c10-0a37-2c97-d4864c0faa80@cs.ucla.edu> <09153aed-361d-4f82-d9ac-b502314769ae@cs.ucla.edu> <83lg91dqd4.fsf@gnu.org> 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 1535239533 10752 195.159.176.226 (25 Aug 2018 23:25:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 23:25:33 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: eliz@gnu.org, monnier@iro.umontreal.ca, pipcet@gmail.com, emacs-devel@gnu.org To: rms@gnu.org, Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 26 01:25:28 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 1fthvr-0002dm-3A for ged-emacs-devel@m.gmane.org; Sun, 26 Aug 2018 01:25:27 +0200 Original-Received: from localhost ([::1]:47365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fthxw-0000B8-Uz for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 19:27:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fthxq-0000B3-Qi for emacs-devel@gnu.org; Sat, 25 Aug 2018 19:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fthxp-00013Q-VJ for emacs-devel@gnu.org; Sat, 25 Aug 2018 19:27:30 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37720) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fthxk-0000o6-9E; Sat, 25 Aug 2018 19:27:24 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6DDA1160778; Sat, 25 Aug 2018 16:27:22 -0700 (PDT) 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 KwbS8CpAZj_7; Sat, 25 Aug 2018 16:27:21 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 86E3D16081D; Sat, 25 Aug 2018 16:27:21 -0700 (PDT) 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 iK4GXuEgaK6n; Sat, 25 Aug 2018 16:27:21 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3A5AE160778; Sat, 25 Aug 2018 16:27:21 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:228917 Archived-At: > > I'm pretty sure that I've written code that's essentially along the > > lines of > > > (when list-of-numbers > > (let ((i most-positive-fixnum)) > > (dolist (a list-of-numbers) > > (setq i (min i a))) > > i)) > > > to get the smallest number in a set. > > This seems to be a real problem. It is a real problem, but not a serious one. A few days ago I audited Emacs master for all uses of most-positive-fixnum and most-negative-fixnum, and in commit a4a3c92e9de59bd0251f36326375cce898919edc I fixed five instances of problems like the one mentioned above. After doing this exercise, my impression is that although this problem is real it is not serious. The unfixed code was already broken on Emacs 26, as integers that exceeded most-positive-fixnum wrapped around silently, breaking the min calculations in a different way. With bignums in place the unfixed code was still broken, but bignums did not introduce a bug that wasn't there already. Also, many of these calculations involve things like column counts or window positions, for which it's extremely unlikely that users will go beyond fixnum limits, and which can help to explain why the dubious code in question has remained unfixed in Emacs for so long. Although we should fix such limitations, misbehavior is so unlikely here that it's not high priority. In case you're curious, here are the remaining dubious instances of most-negative-fixnum and most-positive-fixnum in the Emacs master source, and what they mean in terms of correctness. This should give you a deeper feel for thie issue. * Several modules assumes that buffer sizes fits into fixnums. This assumption is correct for Emacs master, though it will become dubious if we change Emacs to support buffer sizes greater than most-positive-fixnum. The affected modules are emacs-lisp/syntax.el, org/org-list.el, progmodes/cc-engine.el, progmodes/js.el, and simple.el. * net/tramp-sh.el contains some assumptions that file sizes and other attributes that don't fit into fixnums are converted to floats by the underlying drivers. This assumption won't be true of list-attributes, and presumably shouldn't be true of tramp's other drivers (though I don't know the details here; I'm handwaving a bit). * gnus/gnus-registry.el and registry.el assume entry counts fit in fixnums. * net/eww.el assumes readability scores are never less than most-negative-fixnum. * org/org-element.el assumes that element keys are fixnums. * subr.el assumes that undo counts fit in fixnum. * xterm.el assumes that Emacs will never run for more than most-positive-fixnum seconds. Some of these assumptions are quite safe, others are a bit more dubious, none seem to represent serious bugs.