|
From: | Paul Eggert |
Subject: | bug#31118: 27.0.50; Can't load/compile websocket in 32bit master |
Date: | Tue, 17 Apr 2018 00:50:57 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 04/15/2018 06:26 PM, Stefan Monnier wrote:
I think we should first make it emit a warning, while keeping the old broken behavior.
Do you mean 'read' should call 'display-warning' for now? I suppose we could make read-integer-overflow-as-float be a three-state variable: either (1) signal an error, or (2) call display-warning and yield a float, or (3) silently yield a float, and have (2) be the default for now. However, I worry that (2) might lead to further problems, e.g., display-warning is Lisp code that might in turn call 'read' and loop recursively.
The code we're talking about had nonportable code like (eq desktop #xffffffff) that doesn't work on platforms with 30-bit fixnums anyway. If the goal is to make Elisp code safer on 32-bit platforms, --with-wide-int is a simpler and more reliable way to get there (of course bignums would be better but that's a much bigger project). Most Emacs development occurs on 64-bit platforms now, and it's becoming more and more of a pain to insist that programmers must hack on code to make it portable to platforms with 30-bit fixnums.
Admittedly --with-wide-hit is a ~30% CPU performance hit on my circa-2010 AMD desktop. If defaulting to --with-wide-int is too drastic, I hope that the already-existing read-integer-overflow-as-float flag is enough backstop for people who want to run nonportable code on platforms with 30-bit fixnums.
[Prev in Thread] | Current Thread | [Next in Thread] |