GNU bug report logs - #36649
27.0.50; pure space and pdumper

Previous Next

Full log

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

From: Pip Cet <pipcet <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Robert Pluim <rpluim <at> gmail.com>, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#36649: 27.0.50; pure space and pdumper
Date: Fri, 5 Mar 2021 03:00:03 +0000

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

On Thu, Mar 4, 2021 at 9:52 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 3/4/21 6:56 AM, Robert Pluim wrote:
> >      Pip> - zero vector handling depends on Qnil being all zero in memory
> >
> > I think Emacs already assumes Qnil == 0, since there are places that
> > use ! to check for Qnil rather than using NILP.
>
> The convention is to put a "verify (NIL_IS_ZERO);" near the rare bits of
> code that assume Qnil is all-bits-zero.

That would be nice, but I'm quite certain there are places in the code
that rely on this identity without doing that...

> This is to help out any
> hypothetical future developer who wants to change Qnil to be some other
> value. Currently there are only two such locations. (There is one other
> location that uses NIL_IS_ZERO for an optimization.)

When I did the NaN boxing thing, I remember seeing quite a few 0.0s
popping up where I was expecting nil :-)

Anyway, it's easy enough to remove the assumption. Here's the current patch.

Pip

[0001-Remove-pure-space-Bug-36649.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.