bug#32463: 27.0.50; (logior -1) => 4611686018427387903

[Paul Eggert <eggert@cs.ucla.edu>]

> I'm not sure what is on your list of remaining issues, but here is mine:
> 
> a) A bug in bignumcompare for 64bit Windows. Patch is here:
>    http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00487.html

That patch doesn't go far enough, I'm afraid, as there are other bugs in bignum 
comparison. For example, NaNs vs bignums don't always work. And while we're in 
the neighborhood one can more cheaply compare a fixnum to a bignum by simply 
looking at the bignum's sign, as the numeric values don't matter in that case. 
This item is first on my list of things to fix partly because it's relatively easy.

> b) fmod_float has a bug:
>    http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00442.html
> 
> c) Extend Fexpt to support bignums. Patch is here:
>    http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00503.html
> 
> d) Extend Fceiling, Ffloor, Fround and Ftruncate to support bignums by
>    updating rounding_driver.

These are all news to me; thanks for the list.

There are some relatively minor things involving removal of assumption that 
there are no padding bits (OK, so Emacs is not likely to run on Crays any time 
soon, but it's easy to port).

My bigger concern is memory management, along with integer overflow in size or 
bitcount calculation. Copies are made of bignums when not needed, behavior is 
dicey if memory is exhausted during bignum computation, and I'm afraid C-g will 
have problems when bignums get large. I don't have a good handle on this stuff 
yet. I have put in some sanity checks (e.g., see check_bignum_size in emacs.c) 
but I suspect more are needed. In particular, Fexpt will need to be careful as 
it is a good way to explode a bignum's size.