From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Date: Sun, 25 Aug 2024 18:39:57 +0300 Message-ID: <868qwkligi.fsf@gnu.org> References: <871q2c4uf6.fsf@protonmail.com> <87v7zo3d6m.fsf@protonmail.com> <86a5h0lkrg.fsf@gnu.org> <87le0k3a81.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18902"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72802@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 25 17:40:36 2024 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 1siFM3-0004oC-Nx for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Aug 2024 17:40:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1siFLk-0002pZ-GO; Sun, 25 Aug 2024 11:40:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1siFLi-0002pL-80 for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 11:40:14 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1siFLg-0003fW-5D for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 11:40:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=Lxz8qYewWjU35Q/pvH9yM/kgFam9J6tcLvtrdxqP0oY=; b=kDaUJRCcb0SSv/d448kRnQ5Iinx5LbhOPJa0jgIWy39qrWa+bmomyh1YvzZSqANAsPqmwU3Qr2Naa/ZaaY6ka5DWIHSTlA/Hg8iSLQ0rqXW51T+PBqtQ+SyDOEJFoLWKtlOJoI7REliagNzqutzkBnePKaYdpNdrLD9qx0ymropoaepIU4Ot3zQAw0KxJi9+ocvDGVR+2Fis2Zx5v9bk+k+eKY8I/bBhqYiBfnNZV15yNGHvMLj+RGlCwVbiabFLKuk0HfLDdVnVlvY+YjRPT2R7pl/HylABDKDzGVCtzSfJqhSYcqVytlRIn0laU82RS5sg3EFA5olwO41WZQ4mgg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1siFMT-0001aD-VZ for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 11:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 15:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs Original-Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.17246004586066 (code B ref 72802); Sun, 25 Aug 2024 15:41:01 +0000 Original-Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 15:40:58 +0000 Original-Received: from localhost ([127.0.0.1]:43166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFMQ-0001Zm-7r for submit@debbugs.gnu.org; Sun, 25 Aug 2024 11:40:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFMO-0001ZV-65 for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 11:40:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1siFLT-0003SR-Kc; Sun, 25 Aug 2024 11:39:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Lxz8qYewWjU35Q/pvH9yM/kgFam9J6tcLvtrdxqP0oY=; b=jzgR5lVw1PeJ j83CUuaH7AJTSmUfjB2O7beYcBba2Zk5EQT/kWkBwoT/2LDFyyyUxh7YP27+HtdXKHZWGn5tPHgFd 6+vk8dOO6xq18ajUYfQ+x7LsQFi4WE48+OTNdDvnXd+FmLw3dQPo6jyNPvv9i1UL5IhtlrBwYCgy9 tba5yvVH9TLPZFWxu3fIZrYKQMO5egfMPvgUuY1YPJB6TVuAEf4s/Hs4zkOJbXEEGSLaX7zGyVmXj PhoGSPbwQwL6cQSGV35fBivt7iJZuNO0Y6FOUh1noZMDtSnkP/cSA9DbQVoi6V7lCVcrjPPJq8vAL K7xf6OSo0vMO4YekNYmOpQ==; In-Reply-To: <87le0k3a81.fsf@protonmail.com> (message from Pip Cet on Sun, 25 Aug 2024 15:15:14 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:290743 Archived-At: > Date: Sun, 25 Aug 2024 15:15:14 +0000 > From: Pip Cet > Cc: 72802@debbugs.gnu.org > > > Not even on master, I think, unless we see a bug related to it that is not > > caused by a specially-concocted Lisp program or GDB command. > > It's a clear bug, whether or not the Lisp programs that cause it are > "specially-concocted" (what's that supposed to mean, anyway? We can't > just delay fixing what are clearly bugs until they pop up on random > users' machines!) We certainly can, and do. Is there any code out there that compares char-tables and is affected by this? > So I think it's important to fix this soon (not "now") on the master > branch. I disagree, at least for now, sorry. char-tables have been stable for decades, so any change there should ideally be part of some significant enhancement that justifies the potential destabilization. Elimination of pure space or some similar change fits the bill. > > If this is required for the no-pure-space branch, I think you should > > install this on that branch. Then it will be merged together with the > > branch. > > It's not, it just popped up during work on that branch. Popped up how? In any case, there's nothing wrong with fixing that as part of a much larger changeset, which gives us significant gains. > > I'm not sure we want to pay this cost. What bothers me is mainly the > > run-time cost of extracting integers from Lisp objects. > > That might be noticeable on 32-bit machines with EMACS_WIDE_INT, I > suppose, or on very old machines where memory isn't so much slower than > register manipulation. > > > char-table is > > supposed to be very efficient, both memory-wise and CPU-wise, and I > > think the performance here trumps simplicity. > > How about using an "ordinary" pseudovector with its non-Lisp elements at > the end? Not even that, I think. Some of the char-table are accessed in the inner-most loops of the display code, and were at the time optimized especially for that purpose. I'm not interested in making changes there for minor simplifications. > >> BTW, I'm surprised this code returns nil; I think that should be > >> documented. > >> > >> (setq a (make-char-table nil)) > >> (setq b (make-char-table nil)) > >> (aset a 1 nil) > >> (dotimes (i (max-char)) > >> (unless (equal (aref a i) (aref b i)) > >> (error "i = %S" i))) > >> (equal a b) > > > > Why are you surprised? Setting a single cell of a char-table changes > > its structure, usually in quite a radical way. 'aref' does some very > > special things for char-tables; the semantics of accessing an element > > of a vector is only correct superficially, not in the details. > > Indeed, and I expected (and still expect) 'equal' to ignore such > details. No, 'equal' compares components literally. > > The internals of a char-table are not really documented in the ELisp > > manual; the description there is mostly phenomenological, without any > > details. > > I don't think 'equal' behavior is part of those "internals" Indeed, it isn't. But if the internals are described in enough detail, people will be able to understand why 'equal' returns nil in your case. > > If you want to document the internals, I think the proper > > Not the internals, just how 'equal' works. Why is it important? The doc string of 'equal' already says Return t if two Lisp objects have similar structure and contents. The two char-tables you are comparing have different structure, so 'equal' returns nil. What else would you like to document there?