bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 5 Aug 2023 10:45:37 +0000
> Cc: 65051@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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.