Re: [PATCH] Fix a bug with XEmacs and bignum support.

Re: [PATCH] Fix a bug with XEmacs and bignum support.

[Reiner Steib]

On Sun, Jan 11 2009, Aidan Kehoe wrote:

> 2009-01-11  Aidan Kehoe  <kehoea@parhasard.net>
>
> 	* lisp/nnfolder.el (nnfolder-read-folder): 
> 	The (lsh -1 -1) trick to generate the greatest positive fixnum
> 	value doesn't work under an XEmacs with bignum support; use the
> 	most-positive-fixnum constant instead, available since GNU Emacs
> 	21.1 and XEmacs 21.1. 

most-positive-fixnum is only available in Emacs 21 when requiring CL.
But as CL is required (for ignore-errors), I think this change is
fine, so I have installed it.

> --- xemacs-packages/gnus/lisp/nnfolder.el	2006/03/16 04:18:02	1.7
> +++ xemacs-packages/gnus/lisp/nnfolder.el	2009/01/11 12:19:26
> @@ -899,7 +899,7 @@
>  	      (active (or (cadr (assoc group nnfolder-group-alist))
>  			  (cons 1 0)))
>  	      (scantime (assoc group nnfolder-scantime-alist))
> -	      (minid (lsh -1 -1))
> +	      (minid most-positive-fixnum)
>  	      maxid start end newscantime
>  	      novbuf articles newnum
>  	      buffer-read-only)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [PATCH] Fix a bug with XEmacs and bignum support.

[Aidan Kehoe]

 Ar an t-aonú lá déag de mí Eanair, scríobh Reiner Steib: 

 > On Sun, Jan 11 2009, Aidan Kehoe wrote:
 > 
 > > 2009-01-11  Aidan Kehoe  <kehoea@parhasard.net>
 > >
 > > 	* lisp/nnfolder.el (nnfolder-read-folder): 
 > > 	The (lsh -1 -1) trick to generate the greatest positive fixnum
 > > 	value doesn't work under an XEmacs with bignum support; use the
 > > 	most-positive-fixnum constant instead, available since GNU Emacs
 > > 	21.1 and XEmacs 21.1. 
 > 
 > most-positive-fixnum is only available in Emacs 21 when requiring CL.

Oops, you’re right, it was included it in C just after the release. Thanks
for checking.

 > But as CL is required (for ignore-errors), I think this change is
 > fine, so I have installed it.

It’s not, though, it needs to be something like the following in that case,
since CL is available at compile time and not necessarily at runtime: 

--- /tmp/aidan/nnfolder.el.orig	2009-01-11 15:50:39.000000000 +0000
+++ /tmp/aidan/nnfolder.el	2009-01-11 15:50:16.000000000 +0000
@@ -899,7 +899,9 @@
 	      (active (or (cadr (assoc group nnfolder-group-alist))
 			  (cons 1 0)))
 	      (scantime (assoc group nnfolder-scantime-alist))
-	      (minid (lsh -1 -1))
+	      (minid (or (and (boundp 'most-positive-fixnum)
+			      most-positive-fixnum)
+			 134217727))
 	      maxid start end newscantime
 	      novbuf articles newnum
 	      buffer-read-only)

An (eval-when-compile most-positive-fixnum) isn’t appropriate, because the
compile-time constant could be from a 64-bit machine, which would silently
overflow in the Lisp reader under GNU on a 32-bit machine, and break the
algorithm.

-- 
¿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@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Re: [PATCH] Fix a bug with XEmacs and bignum support.

[Reiner Steib]

On Sun, Jan 11 2009, Aidan Kehoe wrote:

>  Ar an t-aonú lá déag de mí Eanair, scríobh Reiner Steib: 
>  > most-positive-fixnum is only available in Emacs 21 when requiring CL.
>
> Oops, you’re right, it was included it in C just after the release. Thanks
> for checking.
>
>  > But as CL is required (for ignore-errors), I think this change is
>  > fine, so I have installed it.
>
> It’s not, though, it needs to be something like the following in that case,
> since CL is available at compile time and not necessarily at runtime: 
>
> --- /tmp/aidan/nnfolder.el.orig	2009-01-11 15:50:39.000000000 +0000
> +++ /tmp/aidan/nnfolder.el	2009-01-11 15:50:16.000000000 +0000
> @@ -899,7 +899,9 @@
>  	      (active (or (cadr (assoc group nnfolder-group-alist))
>  			  (cons 1 0)))
>  	      (scantime (assoc group nnfolder-scantime-alist))
> -	      (minid (lsh -1 -1))
> +	      (minid (or (and (boundp 'most-positive-fixnum)
> +			      most-positive-fixnum)
> +			 134217727))

> An (eval-when-compile most-positive-fixnum) isn’t appropriate, because the
> compile-time constant could be from a 64-bit machine, which would silently
> overflow in the Lisp reader under GNU 

s/GNU/Emacs/, please. :-)

> on a 32-bit machine, and break the algorithm.

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?

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).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [PATCH] Fix a bug with XEmacs and bignum support.

[Aidan Kehoe]

 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@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Re: [PATCH] Fix a bug with XEmacs and bignum support.

[Katsumi Yamaoka]

>>>>> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> I would have expected...

> 	      (minid (or (and (boundp 'most-positive-fixnum)
> 			      most-positive-fixnum)
> 			 (lsh -1 -1)))

That looks good.  With the compiled nnfolder.el in Emacs 21 I got:

Debugger entered--Lisp error: (void-variable most-positive-fixnum)
  nnfolder-read-folder("test")
  nnfolder-possibly-change-group("test" "")
  nnfolder-request-accept-article("test" "" t)
  gnus-request-accept-article("nnfolder:test" nil t t)
  gnus-summary-move-article(nil nil nil copy)
  gnus-summary-copy-article(nil)
* call-interactively(gnus-summary-copy-article)