GNU bug report logs - #32485
27.0.50; Problem with zerop on 32-bit platforms

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32485 in the body.
You can then email your comments to 32485 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Problem with zerop on 32-bit platforms
Date: Mon, 20 Aug 2018 14:12:54 -0400

Evaluating (zerop (lsh -1 32)) on 32-bit Cygwin yields

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p 
-4294967296)

I realize that the fate of lsh is still being debated, but I think
there's a problem with zerop anyway, because directly evaluating (zerop
-4294967296) leads to the same error.

I encountered this problem because vc-hg-state-fast contains the
following:

         ;; We want to store 32-bit unsigned values in fixnums.
         (zerop (lsh -1 32))

Aside from the fact that this leads to an error, it may need to be
changed once a decision is made about lsh.



In GNU Emacs 27.0.50 (build 10, i686-pc-cygwin)
 of 2018-08-20 built on moufang
Repository revision: ecd7a9407711ebe24d7e07d4402a2d66754ee693

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32485: 27.0.50; Problem with zerop on 32-bit platforms
Date: Mon, 20 Aug 2018 19:46:39 +0100

On Mon 20 Aug 2018, Ken Brown wrote:

> Evaluating (zerop (lsh -1 32)) on 32-bit Cygwin yields
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p 
> -4294967296)
>
> I realize that the fate of lsh is still being debated, but I think
> there's a problem with zerop anyway, because directly evaluating (zerop
> -4294967296) leads to the same error.

Could this be bug#32477 ? Please try the patch I posted in:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-08/msg00467.html

    AndyM

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Andy Moreton <andrewjmoreton <at> gmail.com>, 32485 <at> debbugs.gnu.org
Subject: Re: bug#32485: 27.0.50; Problem with zerop on 32-bit platforms
Date: Mon, 20 Aug 2018 15:54:46 -0400

On 8/20/2018 2:46 PM, Andy Moreton wrote:
> On Mon 20 Aug 2018, Ken Brown wrote:
> 
>> Evaluating (zerop (lsh -1 32)) on 32-bit Cygwin yields
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
>> -4294967296)
>>
>> I realize that the fate of lsh is still being debated, but I think
>> there's a problem with zerop anyway, because directly evaluating (zerop
>> -4294967296) leads to the same error.
> 
> Could this be bug#32477 ? Please try the patch I posted in:
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-08/msg00467.html

Yes, that does fix the error.  Thanks.

But let's leave the bug open, because vc-hg-state-fast might still need 
attention.  Currently (zerop (lsh -1 32)) returns nil on all platforms, 
so it's useless; but that might change.

Ken

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32485: 27.0.50; Problem with zerop on 32-bit platforms
Date: Mon, 20 Aug 2018 22:28:00 +0100

On Mon 20 Aug 2018, Ken Brown wrote:

> On 8/20/2018 2:46 PM, Andy Moreton wrote:
>> On Mon 20 Aug 2018, Ken Brown wrote:
>>
>>> Evaluating (zerop (lsh -1 32)) on 32-bit Cygwin yields
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
>>> -4294967296)
>>>
>>> I realize that the fate of lsh is still being debated, but I think
>>> there's a problem with zerop anyway, because directly evaluating (zerop
>>> -4294967296) leads to the same error.
>>
>> Could this be bug#32477 ? Please try the patch I posted in:
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-08/msg00467.html
>
> Yes, that does fix the error.  Thanks.

Good to confirm that its the same underlying problem (but note that an
update on that bug shows further fixes are needed).

> But let's leave the bug open, because vc-hg-state-fast might still need
> attention.  Currently (zerop (lsh -1 32)) returns nil on all platforms, so
> it's useless; but that might change.

Agreed. That may need fixing after the semantics of lsh are sorted out.

    AndyM

Message #19 received at 32485-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 32485-done <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32485: 27.0.50; Problem with zerop on 32-bit platforms
Date: Tue, 21 Aug 2018 13:54:11 -0700

[Message part 1 (text/plain, inline)]

> vc-hg-state-fast might still need 
> attention.  Currently (zerop (lsh -1 32)) returns nil on all platforms, 
> so it's useless; but that might change

This prompted me to audit the uses of lsh in the Emacs source code. I found and 
fixed a few glitches by installing the attached patch; in particular it fixes 
vg-hg-state-fast by using ash instead, as ash's semantics are clear and not 
subject to change. This patch goes further in this direction by replacing lsh 
with ash when either will do.

As this fixes the remaining problems mentioned in this bug report, I'm boldly 
closing the report.

[0001-Audit-use-of-lsh-and-fix-glitches.patch (text/x-patch, attachment)]

Previous Next

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