[debbugs-tracker] bug#30408: closed (24.5; (format "%x" large-number) produces incorrect results)

[GNU bug Tracking System]

Your message dated Thu, 29 Mar 2018 11:09:45 -0700
with message-id <address@hidden>
and subject line Re: Checking for loss of information on integer conversion
has caused the debbugs.gnu.org bug report #30408,
regarding 24.5; (format "%x" large-number) produces incorrect results
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
30408: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30408
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: 24.5; (format "%x" large-number) produces incorrect results Date: Sat, 10 Feb 2018 17:22:53 +1100

I wrote this originally on https://emacs.stackexchange.com/questions/38710/why-does-format-x-some-large-number-produces-incorrect-results and a poster recommended I mention this here.

I wanted the hexadecimal string for a large integer such as below:

(format "%x" 2738188573457603759)

This returns 2600000000f95c00 which is incorrect, it should be 2600000000f95caf.

The value of most-positive-fixnum on my box is 0x1fffffffffffffff which is less than the number I'm supplying above.

As a user I'm a bit baffled what is happening. The manual indicates integers larger than this range are converted to a floating-point number which is a concern for precision but I suspect this is what is biting me here?

I should have known there was an issue with this number since normally I evaluate them directly using eval-last-sexp and it didn't show the octal/hex variants.. :)

I wonder why Emacs Lisp doesn't support bignums by default, so precision would not be an issue?

--- End Message ---

--- Begin Message --- Subject: Re: Checking for loss of information on integer conversion Date: Thu, 29 Mar 2018 11:09:45 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/29/2018 04:11 AM, Eli Zaretskii wrote:

I'd suggest, for a good measure, to have a variable which would force
the conversion to floats, avoiding an error even without the trailing
period.  We can later remove that variable, or make it a no-op, if the
danger of breaking existing code turns out low or non-existent.

OK, I did that, by installing the attached into master, after installing the proposed patch.

As a result, unless the user sets the new variable read-integer-overflow-as-float, the Lisp reader now rejects the program (format "%x" 2738188573457603759) by signaling an overflow error. As this was the basis of the original bug report, I'm marking the bug as done.

0001-New-experimental-variable-read-integer-overflow-as-f.patch
Description: Text Data

--- End Message ---