[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65051: internal_equal manipulates symbols with position without chec
From: |
Eli Zaretskii |
Subject: |
bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. |
Date: |
Sat, 05 Aug 2023 13:57:50 +0300 |
> 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.
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Eli Zaretskii, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Eli Zaretskii, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Eli Zaretskii, 2023/08/04
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/05
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.,
Eli Zaretskii <=
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/05
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Eli Zaretskii, 2023/08/05
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/05
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Eli Zaretskii, 2023/08/05
- bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Alan Mackenzie, 2023/08/13
bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled., Mattias Engdegård, 2023/08/05