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

[Eli Zaretskii]

> Date: Fri, 4 Aug 2023 17:06:10 +0000
> Cc: 65051@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> On Fri, Aug 04, 2023 at 18:27:55 +0300, Eli Zaretskii wrote:
> > > Date: Fri, 4 Aug 2023 14:59:58 +0000
> > > Cc: 65051@debbugs.gnu.org, acm@muc.de
> > > From: Alan Mackenzie <acm@muc.de>
> 
> > > > What will happen to the comparison in internal_equal when
> > > > symbols_with_pos_enabled is zero and the two objects have different
> > > > positions, or one has a position, the other doesn't?
> 
> > > In these cases, equal will return nil.  This is correct.
> 
> > It is?  I thought when symbols with position are disabled, symbols
> > that are 'eq', but have different positions, should compare equal?
> > Why not?
> 
> 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?

> That's the theory.  In practice, the handling in internal_equal forgot to
> check for symbols-with-pos-enabled.  That's what I want to fix, now.

I understand, but I question the correctness of your proposed fix.
And for now, I'm utterly confused regarding the expected semantics of
these comparisons when symbols-with-pos-enabled is nil.

> > > In the other case, when two symbols with position have the same base
> > > symbol and the same position, yet aren't identical, this will also return
> > > nil, which is incorrect.
> 
> > How can they be not identical if the symbols and the positions are the
> > same?  Or maybe I don't understand what you mean by "base symbol"?
> 
> 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?