|
From: | Paul Eggert |
Subject: | Re: Using the GNU GMP Library for Bignums in Emacs |
Date: | Wed, 25 Apr 2018 16:29:56 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 04/25/2018 03:40 PM, Richard Stallman wrote:
If we were to support_only_ 64-bit systems, this argument would cease to be valid.
That is easy to arrange; just configure --with-wide-int. This causes Emacs to use 64-bit words on all platforms (or wider, at least in theory). If we made --with-wide-int the default (which I'm more and more thinking would be a good thing, for this and other reasons), then #xffffffff would work and would format the same on all platforms by default, and this would happen regardless of whether we also add bignums to Emacs.
However, I don't see why assuming 64 bits would mean that the argument would cease to be valid. Even with that assumption, we would continue have the same problem with numbers like #xffffffffffffffff that exceed Emacs fixnum range when words are 64 bits.
Yes, because after your response (which talked about what happens in C), you wrote "I contend that we want the same behavior in Emacs Lisp, too." Sorry if I misunderstood you.I responded to a statement about what happens in C. Did you misread that as a proposal to change Emacs?
I think part of the problem here, is that once we have bignums then there will no problem representing unsigned values that are too large to fit into (say) 30-bit signed integers, so there will be no problem in having %x treat integers like Common Lisp and Python do: programs that want to do I/O of numbers as hexadecimal strings will be able to read and print them with %x and they'll all work just fine even if the numbers contain 8 or 16 or more hexadecimal digits. The problem arises in Emacs Lisp only because it is limited to fixnums now.
[Prev in Thread] | Current Thread | [Next in Thread] |