GNU bug report logs - #38912
27.0.60; PDumper meets segmentation fault when evil is loaded

Previous Next

Full log

Message #94 received at 38912 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> gmail.com>
Cc: niwtrx <at> icloud.com, 38912 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil
 is loaded
Date: Tue, 07 Jan 2020 15:03:21 -0500

>> so the problem doesn't affect only byte-compiled objects but also
>> overlays, markers, windowconfigs, chartables, and fonts, AFAICT.
> True, but then, those don't make much sense as hash keys in an
> equal-based hash table.

Comparing markers with `equal` does make some kind of sense.
And `sxhash-equal` needs to be consistent with it, regardless if we
think it makes sense to index an equal-hash-table with markers (or
objects containing markers).

> I don't think bytecode objects make sense as
> hash keys in an equal-based hash table,

I agree that comparing function objects is fundamentally unreliable, yet
we do that in several places in Elisp: it's not super common, but it's
not rare either, and having a better approximation of "behaves
identically" than `eq` is occasionally useful.

> on its position, for example, makes little sense: when the marker
> moves, the hash value would change.

Comparison with `equal` suffers from this problem in many more cases
than just markers (cons cells, vectors, strings, ...).

> (deduplicating identical bytecode objects used as constants in other
> bytecode objects appears to save quite a bit of space),

I'm curious where you've seen that (I haven't looked at it, but indeed
it's quite possible that the byte-compiler "often" ends up generating
identical byte objects).


        Stefan

Previous Next

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