[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded

From: Pip Cet
Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded
Date: Mon, 6 Jan 2020 17:13:40 +0000

Summary, since I'm CCing emacs-devel:

For bytecode objects, equal-equality does not imply sxhash-equality.
That led to an assertion failure in the pdumper code, even though the
pdumper code itself is apparently correct; it simply does not allow
for paradoxical behavior of hash tables with bytecode keys. (The
muffled sound you hear in the background is my trying not to point out
that eq-vs-eql leads to similar paradoxes).

On Mon, Jan 6, 2020 at 5:01 PM Daniel Colascione <dancol@dancol.org> wrote:
> >> Again, I doubt this is related to the original bug. That `equal'
> >> behaves weirdly like this is a problem I've mentioned before (when
> >> (equal a b) signals but (equal b a) succeeds), but the consensus then
> >> was not to change it, so it's possible this is only the rehashing
> >> check needing to be more careful.
> This consensus is wrong. We need to make equality imply sxhash equality or
> very odd things (like this) will happen.

I agree absolutely, of course, and maybe there's a consensus for
fixing equal for bytecodes but leaving it unfixed for cases in which
(equal a b) signals but (equal b a) does not.

> C++ and Java both require this
> relationship between hash code equality and object equality, and we should
> too.

We do document it, we just don't obey our documented API.

> Can we just fix the bytecode sxhash bug?

Is it too late to fix this for Emacs 27? If the answer is no, would a
good fix be to make equal=eq for bytecode objects? That should come
close to the old behavior, and we can fix things properly (by fixing
sxhash to hash byte code objects) on master.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]