[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making 'eq' == 'eql' in bignum branch

From: Paul Eggert
Subject: Re: Making 'eq' == 'eql' in bignum branch
Date: Sat, 25 Aug 2018 16:27:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

   > 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 

* 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]