[Top][All Lists]

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

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

From: Paul Eggert
Subject: bug#30408: Checking for loss of information on integer conversion
Date: Tue, 27 Mar 2018 16:19:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Here's a patch that I hope addresses the main problem. The basic idea is to avoid the confusion exemplified in Bug#30408 by changing Emacs so that it ordinarily signals an error if it reads a program that contains an integer literal that is out of fixnum range. However, if the out-of-range literal is followed by '.' then Emacs continues to silently convert it to floating-point; this is intended as an escape hatch for any programs that need the old behavior (I expect this'll be rare). Thus, on 32-bit Emacs, plain '536870912' in a program causes Emacs to signal an overflow while loading the program, whereas '536870912.' is treated as a floating-point number as before. (On 64-bit Emacs, the same two literals are both integers, as before.)

Unlike my previous proposal, this patch does not affect the behavior of string-to-integer. As I understand it, that was a primary source of qualms about the previous proposal.

I've tested this on both 32- and 64-bit Emacs on master. This patch has helped me to find a couple of integer portability bugs which I already fixed on master.

Attachment: 0001-Lisp-reader-now-checks-for-integer-overflow.patch
Description: Text Data

reply via email to

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