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#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Date: Fri, 04 Aug 2023 21:01:30 +0300 Message-ID: <838raqvg91.fsf@gnu.org> References: <83leeqvpx8.fsf@gnu.org> <83h6pevnd0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65051@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 04 20:02:28 2023 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 1qRz88-0005TT-K0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Aug 2023 20:02:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRz7l-0001aj-5m; Fri, 04 Aug 2023 14:02:05 -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 1qRz7j-0001aZ-PX for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 14:02:03 -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 1qRz7i-0007cE-6O for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 14:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qRz7i-0001PM-1b for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 14:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Aug 2023 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65051 X-GNU-PR-Package: emacs Original-Received: via spool by 65051-submit@debbugs.gnu.org id=B65051.16911720885365 (code B ref 65051); Fri, 04 Aug 2023 18:02:02 +0000 Original-Received: (at 65051) by debbugs.gnu.org; 4 Aug 2023 18:01:28 +0000 Original-Received: from localhost ([127.0.0.1]:54779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRz79-0001OS-Q5 for submit@debbugs.gnu.org; Fri, 04 Aug 2023 14:01:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRz77-0001OG-PZ for 65051@debbugs.gnu.org; Fri, 04 Aug 2023 14:01:26 -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 1qRz72-0007Wa-9A; Fri, 04 Aug 2023 14:01:20 -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=6eOHH9ynqbewnjLhz50pXj0KRx2plH1p9OPg+Ijp1oM=; b=qH9EdNBOM74d XJ9n5qUoE0yZUKkCAmEzveVWL+S8sjN85WjVBi3xcCvN8MMaAdq/eYWeLAZ/8AN/R6Z+4Q7WKP2SQ /PdoMdWO43+1TGLNAOqTzE4cQbaFWEOAWzR+D3t9clM/893HfDHbMCcdHXRILQY+clhZy/TeHcG0u SpRzpjVrqX5+Yal8HCwKC6ASbVbx/2aKkGBViv31O7g0hUUIi1kXCCcPZA8EYsiwdFZ9WIUMGA3H/ ENsaz6wcQ+J02lhXvwltzdSPSZMlSNae0iC+EmRDI9qt5P70im/tughit7NFsRjjjtHb8rGCU5acz v/7QDaAMkJwxB5ujwB2WBw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRz71-00081m-3t; Fri, 04 Aug 2023 14:01:19 -0400 In-Reply-To: (message from Alan Mackenzie on Fri, 4 Aug 2023 17:06:10 +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:266704 Archived-At: > Date: Fri, 4 Aug 2023 17:06:10 +0000 > Cc: 65051@debbugs.gnu.org > From: Alan Mackenzie > > On Fri, Aug 04, 2023 at 18:27:55 +0300, Eli Zaretskii wrote: > > > Date: Fri, 4 Aug 2023 14:59:58 +0000 > > > Cc: 65051@debbugs.gnu.org, acm@muc.de > > > From: Alan Mackenzie > > > > > What will happen to the comparison in internal_equal when > > > > symbols_with_pos_enabled is zero and the two objects have different > > > > positions, or one has a position, the other doesn't? > > > > In these cases, equal will return nil. This is correct. > > > It is? I thought when symbols with position are disabled, symbols > > that are 'eq', but have different positions, should compare equal? > > Why not? > > With symbols-with-pos-enabled nil, # is not EQ to > #. Neither are these two objects `equal'. This is > because the special, time consuming processing which makes them EQ or > `equal' is enabled by that variable being bound to non-nil. But I thought that with symbols-with-pos-enabled OFF, we just ignore the positions? Truth is, neither the ELisp manual nor the doc string tell us what happens when this variable is nil, they only tell what happens when it's non-nil. So how about documenting that somewhere? > That's the theory. In practice, the handling in internal_equal forgot to > check for symbols-with-pos-enabled. That's what I want to fix, now. I understand, but I question the correctness of your proposed fix. And for now, I'm utterly confused regarding the expected semantics of these comparisons when symbols-with-pos-enabled is nil. > > > In the other case, when two symbols with position have the same base > > > symbol and the same position, yet aren't identical, this will also return > > > nil, which is incorrect. > > > How can they be not identical if the symbols and the positions are the > > same? Or maybe I don't understand what you mean by "base symbol"? > > By "base symbol" I mean 'foo in #. By "identical" I > meant that the two Lisp_Objects would have the same hex value (i.e. be > EQ without symbols-with-pos-enabled), as contrasted to two distinct > Lisp_Objects with the same base symbol, and the same position, i.e. > should be `equal'. So we can have two different copies of #, such that their hex values are different? Isn't that a bug? why don't we conflate such identical symbols?