GNU bug report logs - #31118
27.0.50; Can't load/compile websocket in 32bit master

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 31118 <at> debbugs.gnu.org
Subject: Re: 27.0.50; Can't load/compile websocket in 32bit master
Date: Tue, 17 Apr 2018 00:50:57 -0700

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.

Previous Next

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