bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#30408: Checking for loss of information on integer conversion


From: Eli Zaretskii
Subject: bug#30408: Checking for loss of information on integer conversion
Date: Sun, 18 Feb 2018 19:14:33 +0200

> From: Paul Eggert <address@hidden>
> 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.





reply via email to

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