[Top][All Lists]

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

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

From: Paul Eggert
Subject: bug#32463: 27.0.50; (logior -1) => 4611686018427387903
Date: Sat, 18 Aug 2018 15:56:55 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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:

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:

c) Extend Fexpt to support bignums. Patch is here:

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.

reply via email to

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