GNU bug report logs - #65051
internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 65051 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#65051: internal_equal manipulates symbols with position
 without checking symbols-with-pos-enabled.
Date: Sat, 05 Aug 2023 13:57:50 +0300

> Date: Sat, 5 Aug 2023 10:45:37 +0000
> Cc: 65051 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > With symbols-with-pos-enabled nil, #<symbol foo at 42> is not EQ to
> > > #<symbol foo at 666>.  Neither are these two objects `equal'.  This is
> > > because the special, time consuming processing which makes them EQ or
> > > `equal' is enabled by that variable being bound to non-nil.
> 
> > But I thought that with symbols-with-pos-enabled OFF, we just ignore
> > the positions?  Truth is, neither the ELisp manual nor the doc string
> > tell us what happens when this variable is nil, they only tell what
> > happens when it's non-nil.  So how about documenting that somewhere?
> 
> OK, please see the patch below.

Thanks.

> > > By "base symbol" I mean 'foo in #<symbol foo at 42>.  By "identical" I
> > > meant that the two Lisp_Objects would have the same hex value (i.e. be
> > > EQ without symbols-with-pos-enabled), as contrasted to two distinct
> > > Lisp_Objects with the same base symbol, and the same position, i.e.
> > > should be `equal'.
> 
> > So we can have two different copies of #<symbol foo at 42>, such that
> > their hex values are different?  Isn't that a bug? why don't we
> > conflate such identical symbols?
> 
> No, it's not a bug, anymore than having two `equal' copies of '(a b c)
> would be a bug.

But with symbols we store them in obarray, and obarray ought to find
the existing slot for #<symbol foo at 42> and reuse it, rather than
create a new slot?

> Anyway, I've added code (in that patch below) to check two SWPs properly
> in the event of symbols-with-pos-enabled being nil.
> 
> As already discussed, this is intended for master, not the release
> branch.

Thanks.  I added Stefan to the discussion, since I'd like another pair
of eyes (with more knowledge about this than mine) to eyeball the
changes before we install them.

Previous Next

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