From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#39529: 28.0.50; Metahelp does not contain help text Date: Sun, 16 Feb 2020 11:43:50 -0800 Organization: UCLA Computer Science Department Message-ID: <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CA5EC3F59ADFDE5A87B1BC71" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="72248"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 16 20:48:24 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j3Ptu-000IfJ-OV for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Feb 2020 20:48:22 +0100 Original-Received: from localhost ([::1]:35830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3Ptt-0001Bm-RA for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Feb 2020 14:48:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34789) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3Ppj-00049D-I5 for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 14:44:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3Ppi-0005uB-Ah for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 14:44:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3Ppi-0005tv-6q for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 14:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3Ppi-0005du-5l for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 14:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Feb 2020 19:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39529 X-GNU-PR-Package: emacs Original-Received: via spool by 39529-submit@debbugs.gnu.org id=B39529.158188223921675 (code B ref 39529); Sun, 16 Feb 2020 19:44:02 +0000 Original-Received: (at 39529) by debbugs.gnu.org; 16 Feb 2020 19:43:59 +0000 Original-Received: from localhost ([127.0.0.1]:37730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3Ppf-0005dW-DA for submit@debbugs.gnu.org; Sun, 16 Feb 2020 14:43:59 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3Ppd-0005dF-8A for 39529@debbugs.gnu.org; Sun, 16 Feb 2020 14:43:58 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8AD4516008E; Sun, 16 Feb 2020 11:43:51 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BZpX6rgIcPdK; Sun, 16 Feb 2020 11:43:50 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9277E160093; Sun, 16 Feb 2020 11:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qGgRx-U7UNAH; Sun, 16 Feb 2020 11:43:50 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5FE9B16008E; Sun, 16 Feb 2020 11:43:50 -0800 (PST) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176126 Archived-At: This is a multi-part message in MIME format. --------------CA5EC3F59ADFDE5A87B1BC71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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....) --------------CA5EC3F59ADFDE5A87B1BC71 Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-C-h-C-h-bug-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Improve-C-h-C-h-bug-fix.patch" >From 556cc727e5076d590f8286406e4f46cff3cee41e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 16 Feb 2020 11:36:19 -0800 Subject: [PATCH] Improve C-h C-h bug fix * src/lread.c (read1): Guard against two 'struct Lisp_Vector *' pointers differing only in their most significant bit. Problem reported by Pip Cet (Bug#39529#22). --- src/lread.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/lread.c b/src/lread.c index 1613719eb1..70984d37e1 100644 --- a/src/lread.c +++ b/src/lread.c @@ -2982,10 +2982,13 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list) as 0. This placeholder 0 would lead to accidental sharing in purecopy's hash-consing, so replace it with a (hopefully) unique integer placeholder, which is negative so that it is - not confused with a DOC file offset. Eventually - Snarf-documentation should replace the placeholder with the - actual docstring. */ - EMACS_UINT hash = XHASH (tmp) | (INTMASK - INTMASK / 2); + not confused with a DOC file offset (the USE_LSB_TAG shift + relies on the fact that VALMASK is one bit narrower than + INTMASK). Eventually Snarf-documentation should replace the + placeholder with the actual docstring. */ + verify (INTMASK & ~VALMASK); + EMACS_UINT hash = ((XHASH (tmp) >> USE_LSB_TAG) + | (INTMASK - INTMASK / 2)); ASET (tmp, COMPILED_DOC_STRING, make_ufixnum (hash)); } -- 2.17.1 --------------CA5EC3F59ADFDE5A87B1BC71--