Re: [PATCH] Fix a bug with XEmacs and bignum support.
Ar an t-aonú lá déag de mí Eanair, scríobh Reiner Steib:
If you need to make sure that the correct runtime value is used, I
don't understand why you hard-code 134217727? I would have
expected...
(minid (or (and (boundp 'most-positive-fixnum)
most-positive-fixnum)
(lsh -1 -1)))
What am I missing?
Nothing, that’s a perfectly reasonable approach too.
On a 64-bit machine, I get:
,----[ M-x ielm RET ]
| ELISP> (lsh -1 -1)
| 576460752303423487
| ELISP> (emacs-version)
| "GNU Emacs 21.3.1 (x86_64-suse-linux, X toolkit, Xaw3d scroll bars)\n of 2004-1\
| 0-05 on prokofjieff"
| ELISP> (when (require 'cl) most-positive-fixnum)
| 576460752303423487
`----
When I used this machine(s) some years ago, I always compiled Gnus,
AUCTeX, BBDB, emacs-w3m, etc on a 64-bit machine and ran the compiled
Lisp code on both, 64-bit and 32-bit machines
(/usr/local/share/emacs/site-lisp shared via NFS).
I don’t know if the bug will actually produce noticeable symptoms in
practice--I was curious where the technique had been used, and I found the
code via this search:
http://www.google.com/codesearch?q=lsh\+-1\+-1+file%3A\.el
I haven’t been bitten by the bug.
GNU Emacs certainly does silently overflow, though, writing out a 59-bit
number into byte-compiled code can provoke bugs if that code is run on a
machine where a Lisp integer is 28 bits wide. But you won’t get a
wrong-type-argument or anything of the sort, unless the sign is explicitly
checked.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches