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

[Paul Eggert]

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