GNU bug report logs -
#39529
28.0.50; Metahelp does not contain help text
Previous Next
Reported by: Federico Tedin <federicotedin <at> gmail.com>
Date: Sun, 9 Feb 2020 19:07:01 UTC
Severity: normal
Found in version 28.0.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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....)
[0001-Improve-C-h-C-h-bug-fix.patch (text/x-patch, attachment)]
This bug report was last modified 5 years and 89 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.