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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65051 <at> debbugs.gnu.org, acm <at> muc.de
Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.
Date: Fri, 4 Aug 2023 14:59:58 +0000

Hello, Eli.

On Fri, Aug 04, 2023 at 17:32:35 +0300, Eli Zaretskii wrote:
> > Date: Fri, 4 Aug 2023 14:00:29 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

> > Hello, Emacs.

> > The code in question is in internal_equal (src/fns.c) ~37 lines from its
> > start.  We have:

> >   if (SYMBOL_WITH_POS_P (o1))
> >     o1 = SYMBOL_WITH_POS_SYM (o1);
> >   if (SYMBOL_WITH_POS_P (o2))
> >     o2 = SYMBOL_WITH_POS_SYM (o2);

> > at the top level of the function.  Thus

> >     (equal 'foo #<symbol foo at 42>)

> > will return non-nil, regardless of the setting of
> > symbols-with-pos-enabled.  It should return non-nil only when that flag
> > variable is non-nil.  This is a bug.

> > #########################################################################

> > A simple fix is:

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

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.  Do you think this case is worth bothering
about?  It could easily be amended.

> And which branch are you proposing this change for?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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