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

[Alan Mackenzie]

Hello, Eli.

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.

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.

> > 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'.

The way internal_equal is coded, only certain subtypes of Lisp_vectorlike
have their innards compared.  The other subtypes are simply assumed not
`equal'.  PVEC_SYMBOL_WITH_POS currently isn't among these subtypes,
though this could be changed easily enough.

> > > And which branch are you proposing this change for?

> > master.  It doesn't seem important enough for the release branch.

> OK.

-- 
Alan Mackenzie (Nuremberg, Germany).