From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: 31118@debbugs.gnu.org
Subject: bug#31118: 27.0.50; Can't load/compile websocket in 32bit master
Date: Tue, 17 Apr 2018 00:50:57 -0700 [thread overview]
Message-ID: <100a3631-afa6-ef69-5fa1-6ae95df20c35@cs.ucla.edu> (raw)
In-Reply-To: <jwvfu3wq715.fsf-monnier+emacsbugs@gnu.org>
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.
next prev parent reply other threads:[~2018-04-17 7:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 3:03 bug#31118: 27.0.50; Can't load/compile websocket in 32bit master Stefan Monnier
2018-04-10 22:41 ` Paul Eggert
2018-04-11 1:56 ` Stefan Monnier
2018-04-11 8:07 ` Paul Eggert
[not found] ` <mvmwoxe40f3.fsf@suse.de>
2018-04-11 8:35 ` Paul Eggert
2018-04-11 12:19 ` Stefan Monnier
2018-04-11 12:47 ` Basil L. Contovounesios
2018-04-11 16:22 ` Paul Eggert
2018-04-11 18:37 ` Stefan Monnier
2018-04-11 19:47 ` Glenn Morris
2018-04-15 22:11 ` Paul Eggert
2018-04-16 1:26 ` Stefan Monnier
2018-04-17 7:50 ` Paul Eggert [this message]
2018-04-17 12:18 ` Stefan Monnier
2018-04-17 23:53 ` Paul Eggert
2018-04-18 12:22 ` Stefan Monnier
2018-04-18 19:50 ` Paul Eggert
2018-04-11 16:41 ` Eli Zaretskii
2018-04-11 18:38 ` Stefan Monnier
2018-04-12 12:50 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=100a3631-afa6-ef69-5fa1-6ae95df20c35@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=31118@debbugs.gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.