From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Date: Sun, 6 Aug 2023 15:37:24 +0200 Message-ID: References: <2F680A0A-54B5-42C2-B27B-4E5C6332517A@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15593"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65051@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 06 15:38:18 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 1qSdxZ-0003sf-Vk for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Aug 2023 15:38:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSdxM-0002Eh-6m; Sun, 06 Aug 2023 09:38:04 -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 1qSdxK-0002EZ-IY for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2023 09:38:02 -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 1qSdxK-0006Gw-3r for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2023 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qSdxJ-0007fX-Nw for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2023 09:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Aug 2023 13:38:01 +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.169132905629445 (code B ref 65051); Sun, 06 Aug 2023 13:38:01 +0000 Original-Received: (at 65051) by debbugs.gnu.org; 6 Aug 2023 13:37:36 +0000 Original-Received: from localhost ([127.0.0.1]:58785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSdwt-0007er-Lo for submit@debbugs.gnu.org; Sun, 06 Aug 2023 09:37:36 -0400 Original-Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:61557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSdwp-0007eb-PM for 65051@debbugs.gnu.org; Sun, 06 Aug 2023 09:37:33 -0400 Original-Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b9c907bc68so56730661fa.2 for <65051@debbugs.gnu.org>; Sun, 06 Aug 2023 06:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691329046; x=1691933846; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=PxLy9vnbgu+KvPwBE4D8wpW2nOdnZJ/gUfyXlhxezSA=; b=Y5h0cdTQNn6mO1BfeHjvXhzzM71o0f/bW/RP17G4G+2596ohPq+uxDlgzQKsdKEGrs H4Puly0eRNQKq/1t4rewAYK7eDem7pZMvjq1Ulw+m/e0UJ+sjvvtnO6YdYKGqINbr3Yo IyfvT+mmT0Uizq2ZSFWcmlq14RsvOm69B8Z8aAjy2258JbAI8AbE3qbi/w277ENQb3Kt 13S6bfskI+AdI/VelNDAZZ9Jei4KlSXrr0Y5+/Xl3qB6cQWHSBzbSjqRtsWEi4b6vhf7 F8HVWR38heKQnh6gR0d4aJgXMsBPliqifynlgYtLcO19Hu+17dSOYyvtIefF0KRGZHKW ovow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691329046; x=1691933846; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PxLy9vnbgu+KvPwBE4D8wpW2nOdnZJ/gUfyXlhxezSA=; b=Q1tTp/fTD8faP212eF6kjJE7j66ugU9JJk70DtVCvye2ZVibX+M5hzm4kKFnED4wT6 c2xtWLtZPCTB/HqFDXx0MgA5GQsBGdcu6Ml2FOa0bhzO8hdZXdc5HwPKhELHzCMs9nBW EzLJm+CNc5WHD8Ijn0qqAe0l3z4k5mWSsJ/yjlQ8y2CHVfoiTKyIGE2C9bCHH3XvMo9z xEybp3OwX0F3g4/8QXSFsRRwKtIawz67nxuLd/oBaxQfv6HuXndSb6q/dW8AfHghSiG8 ToEMS99V6YpgQ/Msi+sLngJuEN3d+S20N47uIv9lkcJen/6vK+hQMRsmzyYRGl/fj709 RbgA== X-Gm-Message-State: AOJu0YydIb6t84GCuZRm3bq1ZjFmcew+MREqyT28pdgoH4vW7OL3lNHH lM2uBiD5QyWwQP4ACY/ZONc= X-Google-Smtp-Source: AGHT+IEJuDIU02aRoqxqlHnej46Dkt/Bef1W0Jtjhj5PxPe2F4MldLuazjmXBPiuOunFguCsyMzX7g== X-Received: by 2002:a2e:80da:0:b0:2b9:aa4d:3729 with SMTP id r26-20020a2e80da000000b002b9aa4d3729mr4791739ljg.28.1691329045480; Sun, 06 Aug 2023 06:37:25 -0700 (PDT) Original-Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id m8-20020a2e97c8000000b002b6fed37b18sm1331389ljj.101.2023.08.06.06.37.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2023 06:37:25 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.120.0.1.15) 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:266854 Archived-At: 5 aug. 2023 kl. 23.07 skrev Alan Mackenzie : > diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi > index 34db0caf3a8..a828d303c04 100644 > --- a/doc/lispref/symbols.texi > +++ b/doc/lispref/symbols.texi > @@ -784,9 +784,15 @@ Symbols with Position > @cindex bare symbol > A @dfn{symbol with position} is a symbol, the @dfn{bare symbol}, > together with an unsigned integer called the @dfn{position}. These > -objects are intended for use by the byte compiler, which records in > -them the position of each symbol occurrence and uses those positions > -in warning and error messages. > +objects are stored internally much like vectors Not sure why we want to say how they are stored here. They can be stored = in bubble memory for all the user cares. > , and don't themselves > +have entries in the obarray (though their bare symbols do; > +@pxref{Creating Symbols}). > + > +Symbols with position are for the use of the byte compiler, which > +records in them the position of each symbol occurrence and uses those > +positions in warning and error messages. They shouldn't normally be > +used otherwise. Doing so can cause unexpected results with basic > +Emacs functions such as @code{eq} and @code{equal}. >=20 > The printed representation of a symbol with position uses the hash > notation outlined in @ref{Printed Representation}. It looks like > @@ -798,11 +804,20 @@ Symbols with Position >=20 > For most purposes, when the flag variable > @code{symbols-with-pos-enabled} is non-@code{nil}, symbols with > -positions behave just as bare symbols do. For example, @samp{(eq > -# foo)} has a value @code{t} when that variable > -is set (but @code{nil} when it isn't set). Most of the time in Emacs = this > -variable is @code{nil}, but the byte compiler binds it to @code{t} > -when it runs. > +positions behave just as their bare symbols would. For example, > +@samp{(eq # foo)} has a value @code{t} when the > +variable is set; likewise, @code{equal} will treat a symbol with > +position argument as its bare symbol. > + > +When @code{symbols-with-pos-enabled} is @code{nil}, any symbols with > +position continue to exist, but do not behave as symbols, or have the > +other useful properties outlined in the previous paragraph. = @code{eq} > +returns @code{t} when given identical arguments, and @code{equal} > +returns @code{t} when given arguments with @code{equal} components. Since the components are bare symbols and fixnums, equality and identity = for them are equivalent, right? > + > +Most of the time in Emacs @code{symbols-with-pos-enabled} is > +@code{nil}, but the byte compiler and the native compiler bind it to > +@code{t} when they run. >=20 > Typically, symbols with position are created by the byte compiler > calling the reader function @code{read-positioning-symbols} > @@ -820,7 +835,7 @@ Symbols with Position > a symbol with position, ignoring the position. > @end defvar >=20 > -@defun symbol-with-pos-p symbol. > +@defun symbol-with-pos-p symbol > This function returns @code{t} if @var{symbol} is a symbol with > position, @code{nil} otherwise. > @end defun > diff --git a/src/fns.c b/src/fns.c > index bfd19e8c8f2..d47098c8791 100644 > --- a/src/fns.c > +++ b/src/fns.c > @@ -2773,10 +2773,13 @@ internal_equal (Lisp_Object o1, Lisp_Object = o2, enum equal_kind equal_kind, >=20 > /* A symbol with position compares the contained symbol, and is > `equal' to the corresponding ordinary symbol. */ > - if (SYMBOL_WITH_POS_P (o1)) > - o1 =3D SYMBOL_WITH_POS_SYM (o1); > - if (SYMBOL_WITH_POS_P (o2)) > - o2 =3D SYMBOL_WITH_POS_SYM (o2); > + if (symbols_with_pos_enabled) > + { > + if (SYMBOL_WITH_POS_P (o1)) > + o1 =3D SYMBOL_WITH_POS_SYM (o1); > + if (SYMBOL_WITH_POS_P (o2)) > + o2 =3D SYMBOL_WITH_POS_SYM (o2); > + } OK. This reduces the number of branches in the hot path for ordinary = (non-sympos) code by one while adding one to sym-pos code, and that = should be a fair trade-off. The new branch should be well-predicted but = is still consuming resources. > if (BASE_EQ (o1, o2)) > return true; > @@ -2824,8 +2827,8 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, = enum equal_kind equal_kind, > if (ASIZE (o2) !=3D size) > return false; >=20 > - /* Compare bignums, overlays, markers, and boolvectors > - specially, by comparing their values. */ > + /* Compare bignums, overlays, markers, boolvectors, and > + symbols with position specially, by comparing their values. = */ > if (BIGNUMP (o1)) > return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) =3D=3D = 0; > if (OVERLAYP (o1)) > @@ -2857,6 +2860,13 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, = enum equal_kind equal_kind, > if (TS_NODEP (o1)) > return treesit_node_eq (o1, o2); > #endif > + if (SYMBOL_WITH_POS_P(o1)) /* symbols_with_pos_enabled is false. = */ > + return (internal_equal (XSYMBOL_WITH_POS (o1)->sym, > + XSYMBOL_WITH_POS (o2)->sym, > + equal_kind, depth + 1, ht) > + && internal_equal (XSYMBOL_WITH_POS (o1)->pos, > + XSYMBOL_WITH_POS (o2)->pos, > + equal_kind, depth + 1, ht)); Why recurse here if the components are a bare symbol and a fixnum, = respectively? > /* Aside from them, only true vectors, char-tables, compiled > functions, and fonts (font-spec, font-entity, font-object) > diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el > index 79ae4393f40..9c09e4f0c33 100644 > --- a/test/src/fns-tests.el > +++ b/test/src/fns-tests.el > @@ -98,6 +98,26 @@ > (should-not (equal-including-properties #("a" 0 1 (k "v")) > #("b" 0 1 (k "v"))))) >=20 > +(ert-deftest fns-tests-equal-symbols-with-position () > + "Test `eq' and `equal' on symbols with position." > + (let ((foo1 (position-symbol 'foo 42)) > + (foo2 (position-symbol 'foo 666)) > + (foo3 (position-symbol 'foo 42))) > + (let (symbols-with-pos-enabled) > + (should (eq foo1 foo1)) Thank you! There is nothing wrong with the coverage of these tests with = respect to your changes. However we should make an effort to prevent the compiler from optimising = (eq X X) -> t etc, which it is completely entitled to doing, and also = test both the interpreted and compiled version of `eq` and `equal`. The test bytecomp--eq-symbols-with-pos-enabled already does most of this = for a different reason. Perhaps it can be extended to cover `equal` as = well?