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

Previous Next

Full log

Message #19 received at 30408 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 30408 <at> debbugs.gnu.org
Cc: Emacs-devel <at> gnu.org
Subject: Re: Checking for loss of information on integer conversion
Date: Sun, 18 Feb 2018 19:14:33 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 17 Feb 2018 17:27:37 -0800
> 
> Second, although Emacs still reads large integers like 18446744073709551616 as 
> if they were floating-point, it now signals an error if information is lost in 
> the process. For example, the number 18446744073709551615 now causes the reader 
> to signal an error, since it cannot be represented exactly either as a fixnum or 
> as a floating-point number. If you want inexact representation, you can append 
> ".0" or "e0" to the integer.

I don't think I like this particular effect of the proposed changes.
At the very least there should be an easy way of avoiding the error,
when the number is not under the control of a Lisp program.  E.g., we
represent file sizes as floats if the value overflows an Emacs
integer, but we definitely don't want to risk signaling errors due to
that, e.g. in the likes of ls-lisp.el (and in general any program that
calls file-attributes).

More generally, why signaling an error by default in this case is a
good idea?  Emacs Lisp is not used to write software that controls
aircraft and spaceships, and probably never will, so why shouldn't we
let the programmer request this feature when they need it?  That would
be similar to behavior of equivalent constructs in C programs, where
the inexact exception is AFAIK masked by default.

Previous Next

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