GNU bug report logs -
#65051
internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Fri, 4 Aug 2023 14:01:02 UTC
Severity: normal
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
Full log
Message #17 received at 65051 <at> debbugs.gnu.org (full text, mbox):
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 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> 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).
This bug report was last modified 1 year and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.