bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#39529: 28.0.50; Metahelp does not contain help text


From: Paul Eggert
Subject: bug#39529: 28.0.50; Metahelp does not contain help text
Date: Sun, 16 Feb 2020 11:43:50 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/16/20 8:51 AM, Pip Cet wrote:

it relies on different objects having different hashes, and they might,
by pure chance, have the same hash.

That could happen only if two Lisp vector addresses disagree only in the high-order bit during dumping while on a USE_LSB_TAG platform, something that I didn't think possible on practical Emacs targets. However, the potential problem is easy enough to work around; I installed the attached.

We need to fix the underlying issue, or at least go for the correct
"quick fix", which is to make equal = eq for bytecode objects (this is
almost indistinguishable from the previous behavior, before
sxhash-equal was "fixed").

Give the attached patch I hope no such quick fix is needed.

For what it's worth, the patched code is similar to what Fautoload does; so if there's something wrong here, a similar wrongness has likely been present in Fautoload for some time.

The pure-cons hash, and many other places, assume "equal" means
"equivalent" in some way. That's not true for bytecode objects, where
a function always returning `nil' can be equal to one always returning
`t'.

Could you give an example of this? When I byte-compiled this:

(defun always-t () t)
(defun always-nil () nil)

the .elc file had different bytecode objects #[nil "\300\207" [t] 1] and #[nil "\300\207" [nil] 1]. (The strings are the same, but that's not the issue here.)

the right fix is not to make equal look at
more state than sxhash-equal used to, particularly for Emacs 27.

That would indeed make 'equal' and 'sxhash-equal' consistent. But wouldn't it potentially break a different set of user programs, that (say) rely on 'equal' returning nil when markers point to different locations? So I'd be leery about messing with Emacs 27 in this area.

For the master branch, it's more of a question of what 'equal' should mean. Obviously 'sxhash-equal' must be consistent with 'equal'. If we decide that 'equal' should not inspect marker contents etc., then we should change 'sxhash-equal' accordingly.

(To my mind a better fix would be to introduce the notion of immutability, and for sxhash-equal to inspect only the immutable parts of key contents. But now it's time for me to duck and run....)

Attachment: 0001-Improve-C-h-C-h-bug-fix.patch
Description: Text Data


reply via email to

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