GNU bug report logs - #30408
24.5; (format "%x" large-number) produces incorrect results

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: David Sitsky <david.sitsky <at> gmail.com>
Subject: bug#30408: closed (Re: Checking for loss of information on
 integer conversion)
Date: Thu, 29 Mar 2018 18:10:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#30408: 24.5; (format "%x" large-number) produces incorrect results

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 30408 <at> debbugs.gnu.org.

-- 
30408: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30408
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30408-done <at> debbugs.gnu.org, David Sitsky <david.sitsky <at> gmail.com>
Subject: Re: Checking for loss of information on integer conversion
Date: Thu, 29 Mar 2018 11:09:45 -0700

[Message part 3 (text/plain, inline)]

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 (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: David Sitsky <david.sitsky <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; (format "%x" large-number) produces incorrect results
Date: Sat, 10 Feb 2018 17:22:53 +1100

[Message part 6 (text/plain, inline)]

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?

[Message part 7 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.