[Top][All Lists]

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

Re: Checking for loss of information on integer conversion

From: Eli Zaretskii
Subject: Re: Checking for loss of information on integer conversion
Date: Sun, 18 Feb 2018 22:24:34 +0200

> From: Paul Eggert <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sun, 18 Feb 2018 12:04:20 -0800
> > Emacs Lisp is not used to write software that controls
> > aircraft and spaceships
> Actually, I maintain Emacs Lisp code that controls timestamps used in 
> aircraft 
> and spaceships. I'm not saying that Emacs itself runs the aircraft and 
> spaceships, but it definitely is used to develop software and data used 
> there. 
> As luck would have it, I'm currently engaged in an email thread about time 
> transfer between Earth and Mars (yes, this is really a thing and people are 
> trying to do it with millisecond precision) that is related to a project 
> where I 
> regularly use Emacs Lisp. See the thread containing this message:

Interesting, but not really relevant to the issue at hand, IMO.  I was
talking about real-time control, not off-line calculations.  And I did
propose to have this feature as opt-in, so the kind of calculations
that transfer me to Mars could still be held safely and accurately.

> > More generally, why signaling an error by default in this case is a
> > good idea? ...  That would
> > be similar to behavior of equivalent constructs in C programs
> Sure, and C compilers typically issue diagnostics for situations similar to 
> what's in Bug#30408. For example, for this C program:
> int a = 18446744073709553664;
> GCC issues a diagnostic, whereas for the similar Emacs Lisp program:
> (setq b 18446744073709553664)
> Emacs silently substitutes a number that is off by 2048.

I'm okay with flagging such constants during byte compilation.  I was
talking only about run-time diagnostics, not compile-time diagnostics.

> When people write a floating-point number they naturally expect it to have 
> some 
> fuzz. But when they write an integer they expect it to be represented 
> exactly, 
> and not to be rounded.

That is true, but Emacs behaved like it does today for many years, and
I'm worried by the possible breakage such a significant behavior
change could have, including on our own code.

reply via email to

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