GNU bug report logs - #75318
Lisp_Subr header and layout

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Pip Cet <pipcet@HIDDEN>; dated Fri, 3 Jan 2025 14:31:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 23 Jan 2025 11:59:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 23 06:59:28 2025
Received: from localhost ([127.0.0.1]:39574 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tavrr-00020K-UZ
	for submit <at> debbugs.gnu.org; Thu, 23 Jan 2025 06:59:28 -0500
Received: from mail-4316.protonmail.ch ([185.70.43.16]:49679)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tavrn-0001zy-63
 for 75318 <at> debbugs.gnu.org; Thu, 23 Jan 2025 06:59:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737633556; x=1737892756;
 bh=70TaU/uoAdAPwQXqpuIjHc0TBuyTocbiqbNnd7H995g=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=cn8XtIkf6RnHoilI/lVYYn5KOAJ2uA8c1UjFxKyXE+4gSgM0l0CiHF6y5GDhdaMhP
 BpOaw3MVp4kvGpl5pao/RMBZwCTKT3Vr6ey5t/64LVS04rzVAJ5As10yhLPZfxTGAI
 jDeCgtWRIl/SlzyJPfZiSHwKHJSFCNXrzgpCk4OOD5aeaP48F7UdMX6Mq+XItJmbL5
 oj5BHgUhFruQ/aYefVZmcdeVfCLw6ZAl4qY0Q4Fhn6/TINc1YWSY2tdjPqbx/w7mDC
 tEaeQhjDDSzKF8cNP8w0+pUdxGSUaqg9l3UJoFAd427oB8q+ZEycKrLCr+ZOY8ZGOL
 aSBiSVAdaJL5A==
Date: Thu, 23 Jan 2025 11:59:04 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <875xm57ncy.fsf@HIDDEN>
In-Reply-To: <jwv8qr3ko5c.fsf-monnier+emacs@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <jwv8qr3ko5c.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: d19055cba83fd402bae73f36e773877523178eb1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: Po Lu <luangruo@HIDDEN>, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Stefan Monnier" <monnier@HIDDEN> writes:

>> Ideally, we'd turn these three into plain DEFUNs, with docstrings
>> indicating they're internal functions.  I'd also like to turn the
>> underscores into ordinary dashes in the Lisp function names if we
>> do that.
>
> +1
> Does anyone know why they're not plain DEFUNs?

The sfntfont.c isn't safe to call from Lisp (it assumes it's passed two
vectors of the right size).

Po Lu, I assume it was originally a normal DEFUN and then modified for
performance reasons?  Are those reasons significant enough to keep the
code as it is, in your opinion, until a better solution than turning it
into a safe DEFUN is found?

(I must confess I don't understand the code at all: the first results
are the ones with the fewest number of fields set? Is the list reversed
somewhere else? I'm not saying this code needs more comments, of
course.  If others can understand it easily, I may just have a blind
spot here.)

About the alloc.c non-DEFUNs:

No idea, couldn't find anything, it looks weird in C-h v
gc-cons-threshold.

Nothing in the commit (97ffa339b6d67cebcbefbdfaa2880214adab639c) or bug
discussion (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D37006).

The comment in lisp.h, above Lisp_Subr says:

/* This structure describes a built-in function.
   It is generated by the DEFUN macro only.
   defsubr makes it into a Lisp object.  */

The least we could do is adjust that by expanding the second line.  (In
the nativecomp case, all three lines need fixing.)

The watcher is exposed to Lisp and can be called directly or removed, so
that's not it.

The underscored name is also printed in C-h v gc-cons-threshold, so
hiding it isn't the reason either.

(My drive-by proposal in bug#75632 is to improve display of variable
watchers, for example by starting with:

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 9324cf85454..f4f595aedbe 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -1712,7 +1712,9 @@ help-fns--var-watchpoints
     (when watchpoints
       (princ "  Calls these functions when changed: ")
       ;; FIXME: Turn function names into hyperlinks.
-      (princ watchpoints)
+      (dolist (watchpoint watchpoints)
+        (princ (help-fns-function-name watchpoint))
+        (princ "\n  "))
       (terpri))))

And then fixing help-fns-function-name so we can remove the FIXME.)

No matter whether we change help-fns.el, the name is likely to remain in
the output, so the underscores are confusing; and giving it a proper
symbol seems like a good idea to me, not just because we can then add
the symbol rather than the subr to the watchers list, and that prints
nicely.

If there aren't any good reasons, I'll send a patch turning all three
into DEFUNs and we can discuss that further.  Definitely going to push
this particular change until there's consensus, though.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 17:58:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 12:58:05 2025
Received: from localhost ([127.0.0.1]:36316 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taezN-00088S-0t
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 12:58:05 -0500
Received: from mail-40133.protonmail.ch ([185.70.40.133]:15279)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1taezI-00087n-DK
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 12:58:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737568672; x=1737827872;
 bh=pzVUYpmqIQ/d85Tp0VKJPb5wnTD2EfXX2W6pEhB6QiU=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=e4DOmtjPlz3etGudDJOuzUeHfxkoIU1i/nGBtzaqOm+ZUm4cW/r+Jdc5HLRTfQOb0
 BDTR9mH1gNklUhZNdrTTXq9CCBT5wqMfioaKVHzNUw0k0IbIQAj5BKTS2ZDaFEB4bD
 0pC9nKe2yq8PHA+ZR6RZA3vyoNKuZ8YYA4pX7tijLuJU/TTwq/MuqjUEkTvyxnz4E1
 oA7TAumujLDJ27A+3z5LfUJSmHjHE2JjDolAzOLW83kv0UodG/3bYucHowayz3Zywl
 SsvhuOOEAIsZL1giUTFnFC0bjGCWfAk4g747vKF42nbJznazjNEBb6MkS54OyWVaVI
 jqT0UuL3sS/Eg==
Date: Wed, 22 Jan 2025 17:57:48 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <871pwubujy.fsf@HIDDEN>
In-Reply-To: <86ed0u3irz.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <86wmen2dj1.fsf@HIDDEN> <87frlbc4dz.fsf@HIDDEN>
 <86jzam3m2q.fsf@HIDDEN> <87r04ubzn4.fsf@HIDDEN>
 <86ed0u3irz.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 573ab59b48c609e4bda1a130dc2fa11dd676bcac
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Wed, 22 Jan 2025 16:07:52 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: 75318 <at> debbugs.gnu.org, luangruo@HIDDEN, monnier@HIDDEN
>>
>> (In GDB, with .gdbinit loaded, "p LISPSYM_INITIALLY (Qnil)" prints an
>> unhelpful "{0x0}"; "p lisp_h_Qnil" prints "{0}".  ptype thinks the first
>> is a Lisp_Object (but expands the type to its obscure definition), the
>> second claims to be a singleton array of int.
>
> I guess your build is with check-lisp-objects?  Because here I get

Sorry, meant to mention that and forgot.  It is.

>   (gdb) p LISPSYM_INITIALLY (Qnil)
>   $1 =3D 0
>   (gdb) p lisp_h_Qnil
>   $3 =3D 0
>   (gdb) ptype LISPSYM_INITIALLY(Qnil)
>   type =3D long long
>   (gdb) ptype lisp_h_Qnil
>   type =3D int

I guess your build is with wide Emacs ints, as usual :-)

I'd also forgotten about "whatis", which splits the difference and tells
me the first is a Lisp_Word, not a Lisp_Object.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 16:39:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:39:28 2025
Received: from localhost ([127.0.0.1]:36108 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tadlH-0003eZ-RC
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:39:28 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:58068)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tadlE-0003eC-EW
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:39:25 -0500
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 <eliz@HIDDEN>)
 id 1tadl8-0001HO-41; Wed, 22 Jan 2025 11:39:18 -0500
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=LsCJ2iyhWv4ZJR4QgT3JYyHI/Qa6E+nN+CC55LOHabI=; b=i1t9CtY3CflO
 PRAM1V7dWTzL4kFl9J2HXLT+XVB0OmgIhJa2jfxGChS1+F4ag27jUQn6Spa79l7fnh1f0kH3JMtQt
 rndKrJqjaXwyeAHn8vtgo52QYQthd0ssJktrFEStt0JNqQIwMMRSmj89OziXbG3G1m0VPPpYGvDCZ
 JTbHk7I78KSseButn+U+vwX5bxh/+KevIrGFLPyuiNnqZiWSfTxzTd9rkY0OwIT5aj5FlqvZZ56Jz
 4hXS2KZZLPvzJQiukmTabdJf10PL/K9OXm43E14R6O7rpgM3Dt1oIPBOlRFCqTZ4F16aTRJz2/Irb
 qsW3OLmGHUjb7Nvk9lTg2w==;
Date: Wed, 22 Jan 2025 18:39:12 +0200
Message-Id: <86ed0u3irz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87r04ubzn4.fsf@HIDDEN> (message from Pip Cet on Wed, 22
 Jan 2025 16:07:52 +0000)
Subject: Re: bug#75318: Lisp_Subr header and layout
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <86wmen2dj1.fsf@HIDDEN> <87frlbc4dz.fsf@HIDDEN>
 <86jzam3m2q.fsf@HIDDEN> <87r04ubzn4.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Wed, 22 Jan 2025 16:07:52 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 75318 <at> debbugs.gnu.org, luangruo@HIDDEN, monnier@HIDDEN
> 
> (In GDB, with .gdbinit loaded, "p LISPSYM_INITIALLY (Qnil)" prints an
> unhelpful "{0x0}"; "p lisp_h_Qnil" prints "{0}".  ptype thinks the first
> is a Lisp_Object (but expands the type to its obscure definition), the
> second claims to be a singleton array of int.

I guess your build is with check-lisp-objects?  Because here I get

  (gdb) p LISPSYM_INITIALLY (Qnil)
  $1 = 0
  (gdb) p lisp_h_Qnil
  $3 = 0
  (gdb) ptype LISPSYM_INITIALLY(Qnil)
  type = long long
  (gdb) ptype lisp_h_Qnil
  type = int





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 16:38:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:38:41 2025
Received: from localhost ([127.0.0.1]:36103 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tadkW-0003cp-4w
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:38:40 -0500
Received: from mail-40133.protonmail.ch ([185.70.40.133]:45033)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tadkS-0003cR-22
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:38:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737563909; x=1737823109;
 bh=HpMgern+mbBG/3j8mSqzw2Kn1FqwuaIjppQ+TREIZjI=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=SMjnCEtRaINv4BdmWvU+mwFuQJl4aKCMhEgRgAlZ36EmqzKf0UNh8tVAdmnAI/78P
 gj6Ep7ICDwtYVDCcSrxK9acS3JAqCOR9xy6/PZ6l5tXtgMVAM8A50dY1mKyKjhXUKt
 2JAjBVGD4BegtfKnjIqTfLwBKalcV63ngZeWh0ZxmosTTTjqhw0eDU/Ne6y640OjST
 Jw+1h6f96z1k2bT42hwa4KujyMjPAtpiKLjCdE8T1bWRJ9I3qay0AXbCpSYb80N/Yh
 sTekodTXZMJUmAUiWuqtVr9pJgDvUlbHCpbobHP3xo4DoQ5C6CiELC6Tt6BlfGr9BL
 4oS1CtNj73xSA==
Date: Wed, 22 Jan 2025 16:38:26 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <87ldv2by87.fsf@HIDDEN>
In-Reply-To: <86h65q3k8g.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <8734hbn31e.fsf@HIDDEN>
 <86v7u72cx7.fsf@HIDDEN> <877c6mdfy0.fsf@HIDDEN>
 <86h65q3k8g.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: e3eb131da9e2e1d0300d5b77ab7cb88f34213a0c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: acorallo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Wed, 22 Jan 2025 15:30:24 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: Andrea Corallo <acorallo@HIDDEN>, 75318 <at> debbugs.gnu.org, monnier@ir=
o.umontreal.ca
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> >> Cc: monnier@HIDDEN
>> >> Date: Tue, 21 Jan 2025 23:46:45 +0000
>> >> From:  Pip Cet via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>> >>
>> >> diff --git a/src/lisp.h b/src/lisp.h
>> >> index 9c31630cc1a..46e940dad09 100644
>> >> --- a/src/lisp.h
>> >> +++ b/src/lisp.h
>> >> @@ -2226,12 +2226,12 @@ CHAR_TABLE_SET (Lisp_Object ct, int idx, Lisp=
_Object val)
>> >>        const char *string;
>> >>        Lisp_Object native;
>> >>      } intspec;
>> >> -    Lisp_Object command_modes;
>> >>      /* Positive values: offset into etc/DOC.  Negative values: one's
>> >>         complement of index into the native comp unit's vector of
>> >>         documentation strings.  */
>> >>      EMACS_INT doc;
>> >>  #ifdef HAVE_NATIVE_COMP
>> >> +    Lisp_Object command_modes;
>> >>      Lisp_Object native_comp_u;
>> >>      char *native_c_name;
>> >>      Lisp_Object lambda_list;
>> >
>> > IME, having different definitions of data structures under different
>> > build conditions is a problematic solution: it makes it harder to make
>>
>> That statement applies to the status quo before the patch just as much
>> as it does to the new status, though, right?
>
> Could be; I didn't check.  It's a general statement.
>
>> > safe changes that don't break some build.  Many/most people don't try
>>
>> This doesn't; it's impossible ta safely use the command_modes field for
>> the reasons I explained.
>
> Can you point me to the explanation, or explain again?

GC doesn't trace the field, pdumper doesn't save it; the sole remaining
user expects (and insists) on a Qnil value.  Iff we wanted to fix the
first we'd have to add new users for testing, if we want to fix and test
the second we'd have to add pre-dump users, which is harder.  Pdumper
also asserts that the field isn't used, so it's possible other things
will break, because I'm sure that assertion was put there for a reason.

>> And making it safe without using it at all seems both wasteful and all
>> but impossible: we'd have to test the code somehow, making up usages of
>> a field that hasn't been in real use for a long time.
>
> I just wanted to avoid breaking a build by referencing the struct
> member in a build that doesn't have it.  There's no need to ensure the
> member is always used safely.  Doesn't initializing it to nil solve
> this?

I don't understand that at all, sorry.  If anyone uses the field for
anything but checking its nil-ness in a non-nativecomp build, they
either get a compile-time error or a very frustrating inexplicable
crash.  Changing from the latter to the former is the best we can do.

>> The new patch does still make it possible for someone using only
>> nativecomp builds to accidentally use the field for non-nativecomp
>> subrs.  If someone tried to build that tree without nativecomp, they
>> would get a compiler error, which is the best we can do to warn them of
>> this situation, given the constraint that we use the same structure for
>> nativecomp subrs and primitive ones.
>
> OTOH, adding code that references the field without #ifdef, and
> installing it without trying a non-nativecomp build, will break
> everybody who builds --without-native-compilation.

Indeed. It'd be nice to statically check more things before we push to
master (and, generally, compiling a C program and checking it for errors
are two separate things; the same is true for texinfo, it seems).  I
honestly think we should add a separate "lint" pass (by this or any
other name) sooner rather than later, but right now, we don't.  The best
we can do is CI and breaking the build rather than crashing
inexplicably.

(Random example: print.c exposes the string "unreadeable-function"
(meaning "unreadable-function") to Lisp and expects Lisp to provide it
in some contexts.  Obviously not something GCC can check for during
every build, but if we'd run a weekly typo lint, we could have caught it
in time.  I've let the resident typo expert know, but this probably
requires a bug report and discussion now).

But, again, pie-in-the-sky dreams of a better build system aside, this
is strictly about compile-time errors vs run-time bugs.

>> People might use it, and run into the various bugs that have
>> accumulated.  It's better to remove the unusable field (and there's all
>> that talk about not wasting two words of staticvec, but wasting 1,000
>> words is suddenly okay?).
>
> If this leads to such a significant memory waste, then indeed what I
> proposed is a non-starter, unfortunately.

Insignificant for my current system, unfortunately, which aligns
static Lisp_Subr to 32-byte boundaries (for good reason).  However, as
there are many systems with different alignments and sizes, saving a
32-byte line every fourth time we remove a word has the same expected
benefit as regaining 8 bytes the second we do so.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 16:08:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:08:24 2025
Received: from localhost ([127.0.0.1]:36032 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tadHE-00023f-34
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:08:24 -0500
Received: from mail-10630.protonmail.ch ([79.135.106.30]:58427)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tadGw-00022b-UE
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:08:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737562079; x=1737821279;
 bh=DascabW3/NidouLVXT4fTUAhTI8mdWmhxaPMKn36Cuk=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=iSVsYK1oisVGOtfbcoxKHq4Bfq/ConhGf+LRsXNJVKZIeGXWkn29Kp8wDbHOtIg2r
 n4hd3xsMERWlVnYgSu2AL3Vb7RQ+E/jqjiomeOTDGEJK16fpMU2waEKUrolwGAORZY
 FUl3KCDks7dPjgoUs3LYwJFRV5AVaxoeD64M2nZjuh7jR1P57lKq5MHwnyhFwFKYus
 Mv9qUHL01yQD9pbxFb1f02hCda6tjjyoIEFHPrJR+T9ulm0SO4rqzuiqsa3TTCxv4t
 bIbw5Mh1V2d4qWRvh+if1VlgJ3HErRUIIIK4BQCuTFIt8cMBRw309P8OC2xkL3oYw0
 J5P1rHY8yXUVA==
Date: Wed, 22 Jan 2025 16:07:52 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <87r04ubzn4.fsf@HIDDEN>
In-Reply-To: <86jzam3m2q.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <86wmen2dj1.fsf@HIDDEN> <87frlbc4dz.fsf@HIDDEN>
 <86jzam3m2q.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 9ba372fcefe19aa0cfcc55e979848b397655be55
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Wed, 22 Jan 2025 14:25:22 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: 75318 <at> debbugs.gnu.org, luangruo@HIDDEN, monnier@HIDDEN
>>
>> > For example, in the below:
>> >
>> >>    static union Aligned_Lisp_Subr Swatch_gc_cons_percentage =3D
>> >> -     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) }=
,
>> >> -       { .a4 =3D watch_gc_cons_percentage },
>> >> -       4, 4, "watch_gc_cons_percentage", {0}, lisp_h_Qnil}};
>> >
>> > what is lisp_h_Qnil is relatively easy to understand, whereas the
>> > replacement, viz.:
>>
>> >> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_va=
lue) \
>> >> +  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
>> >> +    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
>> >> +    .min_args =3D minargs,=09=09=09=09=09=09\
>> >> +    .max_args =3D maxargs,=09=09=09=09=09=09\
>> >> +    .symbol_name =3D lname,=09=09=09=09=09=09\
>> >> +    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
>> >> +    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09\
>> >
>> > requires one to look up LISPSYM_INITIALLY, which is
>>
>> If you're saying that LISPSYM_INITIALLY is bad, I agree completely.
>
> It isn't bad, it's that replacing lisp_h_Qnil with it makes the code
> harder to understand (without going crazy with M-.).

> As for LISPSYM_INITIALLY, its name is the main source of confusion:
> the INITIALLY part all but prevents any attempt to get a clear idea
> what the macro does, without actually looking up all the way to the
> basics.  Unless on remembers that by heart, of course (I don't).

I think that second paragraph means that LISPSYM_INITIALLY is, at best,
an unfortunate workaround which may one day be retired.  So, IMHO, yes,
it's bad in an absolute way, but it may be the best option anyway.

(In GDB, with .gdbinit loaded, "p LISPSYM_INITIALLY (Qnil)" prints an
unhelpful "{0x0}"; "p lisp_h_Qnil" prints "{0}".  ptype thinks the first
is a Lisp_Object (but expands the type to its obscure definition), the
second claims to be a singleton array of int.  While all of these are
unhelpful, the last one is dangerous, and we can avoid it by using the
unfortunately-named LISPSYM_INITIALLY.

However, I think Qnil should be usable in static context.  If someone
working on a new GC can't do that (I speak from experience)), they most
likely cannot implement LISPSYM_INITIALLY at all, and have to resort to
some kind of constructor extension; GNU C has one, C++ supports them
natively.

None of that means we should be forced to keep the name, which is
confusing and misleading.

>> > To make the depth of the proverbial rabbit hole at least to some
>> > extent smaller here, could we please refrain from defining
>> > SUBR_NATIVECOMP_INITIALIZER, and instead include the necessary stuff
>> > directly in SUBR_INITIALIZER, with an #ifdef?  Or do you envision
>> > enough other users of SUBR_NATIVECOMP_INITIALIZER to justify yet
>> > another macro?
>>
>> Do you mean
>>
>> #ifdef HAVE_NATIVE_COMP
>> #define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value)=
 \
>>   {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
>>     .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
>>     .min_args =3D minargs,=09=09=09=09=09=09\
>>     .max_args =3D maxargs,=09=09=09=09=09=09\
>>     .symbol_name =3D lname,=09=09=09=09=09=09\
>>     .intspec =3D { .string =3D intspec_value },=09=09=09=09\
>>     .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09=09\
>>     .native_comp_u =3D LISPSYM_INITIALLY (Qnil),=09=09\
>>     .lambda_list =3D LISPSYM_INITIALLY (Qnil),=09=09\
>>     .type =3D LISPSYM_INITIALLY (Qnil),
>>     }}
>> #else
>> #define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value)=
 \
>>   {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
>>     .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
>>     .min_args =3D minargs,=09=09=09=09=09=09\
>>     .max_args =3D maxargs,=09=09=09=09=09=09\
>>     .symbol_name =3D lname,=09=09=09=09=09=09\
>>     .intspec =3D { .string =3D intspec_value },=09=09=09=09\
>>     }}
>> #endif
>>
>> (and, I assume, the same thing for SUBR_HEADER?)
>
> No.  I meant to use #ifdef inside the macro.  But if that is
> impossible in a C macro, I'd even support making this an inline
> function.

My understanding is you cannot use #ifdef inside a macro in GNU C; there
might be a way to use _Pragma in other C versions, but it's horrible.

Similarly, as the standard C we're attempting to use doesn't have
constexpr and inlining functions is always optional, I'm pretty sure
it's still impossible to statically initialize a variable with the
result of calling a function, inline or otherwise.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 16:08:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:08:06 2025
Received: from localhost ([127.0.0.1]:36028 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tadGs-000230-V9
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:08:06 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34548)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tadGq-00022Q-E8
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 11:08:01 -0500
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 <eliz@HIDDEN>)
 id 1tadGh-000572-8G; Wed, 22 Jan 2025 11:07:51 -0500
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=7lmzK/VRDtsUV37kVzuhHwFzM/Yn4qvL4rfA4+ofx/g=; b=dn3ODSBXyutr
 MRXriNcklRbbCq1Q25waq/jEirF23jUJlUY/LyIc9AKx5wFt8tZQlrcXBg7S4wER4jm1NRxP5eIW/
 DzJHFOOnyy8H/oAmP4Z9aATJeulzzafC1ti7U/k/bxzaRlWtvYXXFZFPEgIpq4txejXWjlFNevAHT
 amhiVyJ6LokA17VHTlG5yuiwPTkLx2BQ9AW07QYct5k0BuqmtJPToTf/Ut21DUJwKHX8/6LqqurdR
 VMEatIwHmTWiPuJMaB680fDhDznt+KSkUglP4qNBr8aRnm0N7HJPHf9ggbs07X7PulNk3x+9AQpFd
 AQ7iZDN4VTUfiqpKUJ9qKw==;
Date: Wed, 22 Jan 2025 18:07:43 +0200
Message-Id: <86h65q3k8g.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <877c6mdfy0.fsf@HIDDEN> (message from Pip Cet on Wed, 22
 Jan 2025 15:30:24 +0000)
Subject: Re: bug#75318: Lisp_Subr header and layout
References: <87seq0j7ix.fsf@HIDDEN> <8734hbn31e.fsf@HIDDEN>
 <86v7u72cx7.fsf@HIDDEN> <877c6mdfy0.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: acorallo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Wed, 22 Jan 2025 15:30:24 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: Andrea Corallo <acorallo@HIDDEN>, 75318 <at> debbugs.gnu.org, monnier@HIDDEN
> 
> "Eli Zaretskii" <eliz@HIDDEN> writes:
> 
> >> Cc: monnier@HIDDEN
> >> Date: Tue, 21 Jan 2025 23:46:45 +0000
> >> From:  Pip Cet via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >>
> >> diff --git a/src/lisp.h b/src/lisp.h
> >> index 9c31630cc1a..46e940dad09 100644
> >> --- a/src/lisp.h
> >> +++ b/src/lisp.h
> >> @@ -2226,12 +2226,12 @@ CHAR_TABLE_SET (Lisp_Object ct, int idx, Lisp_Object val)
> >>        const char *string;
> >>        Lisp_Object native;
> >>      } intspec;
> >> -    Lisp_Object command_modes;
> >>      /* Positive values: offset into etc/DOC.  Negative values: one's
> >>         complement of index into the native comp unit's vector of
> >>         documentation strings.  */
> >>      EMACS_INT doc;
> >>  #ifdef HAVE_NATIVE_COMP
> >> +    Lisp_Object command_modes;
> >>      Lisp_Object native_comp_u;
> >>      char *native_c_name;
> >>      Lisp_Object lambda_list;
> >
> > IME, having different definitions of data structures under different
> > build conditions is a problematic solution: it makes it harder to make
> 
> That statement applies to the status quo before the patch just as much
> as it does to the new status, though, right?

Could be; I didn't check.  It's a general statement.

> > safe changes that don't break some build.  Many/most people don't try
> 
> This doesn't; it's impossible ta safely use the command_modes field for
> the reasons I explained.

Can you point me to the explanation, or explain again?

> And making it safe without using it at all seems both wasteful and all
> but impossible: we'd have to test the code somehow, making up usages of
> a field that hasn't been in real use for a long time.

I just wanted to avoid breaking a build by referencing the struct
member in a build that doesn't have it.  There's no need to ensure the
member is always used safely.  Doesn't initializing it to nil solve
this?

> 
> > to build all of the configurations Emacs supports when they make
> > changes, so it is easy to write code which references a struct member
> > that doesn't exist in some build configuration, and thus break it, and
> > miss the fact that build is broken by not trying it.  (It is
> > unrealistic to expect everyone who has write access to the repository
> > to test-build all the possible configurations Emacs supports as a
> > prerequisite for installing a change.)
> 
> I agree, but I don't see how that applies here.  Before the patch, if
> someone had started using nativecomp-only command_modes, we would have
> had very tricky GC/pdumper bugs which would have taken much longer to
> resolve than simply removing an unused field.

Well, both problems exist, they just push us in opposite directions.

> The new patch does still make it possible for someone using only
> nativecomp builds to accidentally use the field for non-nativecomp
> subrs.  If someone tried to build that tree without nativecomp, they
> would get a compiler error, which is the best we can do to warn them of
> this situation, given the constraint that we use the same structure for
> nativecomp subrs and primitive ones.

OTOH, adding code that references the field without #ifdef, and
installing it without trying a non-nativecomp build, will break
everybody who builds --without-native-compilation.

> People might use it, and run into the various bugs that have
> accumulated.  It's better to remove the unusable field (and there's all
> that talk about not wasting two words of staticvec, but wasting 1,000
> words is suddenly okay?).

If this leads to such a significant memory waste, then indeed what I
proposed is a non-starter, unfortunately.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 15:30:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 10:30:39 2025
Received: from localhost ([127.0.0.1]:35916 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tacgg-0000Dg-H8
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 10:30:39 -0500
Received: from mail-10631.protonmail.ch ([79.135.106.31]:25989)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tacgd-0000DK-9s
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 10:30:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737559828; x=1737819028;
 bh=U3Gk54H2ZobZoimYNBGJraaXJqWougiByCxPLse4spw=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=XO9cmrkumbdmISl9wUlclnPetgQv5L1gYX9AwwofgqEZWKuD6LgUbVn6wxOeZvFgx
 FDJD/P2d4islZ9cnbZ9Qgijit5N+ZyjN+Xwl1Khp2F/a3d5Wnq6/PIvKyTlB9LSQgb
 qtTKX1Vkj71cVIUjDJ6r8pYOSCbSz0Cy83QHSe05+vhb9VU6sXylX+6CGz7BNpRI53
 xbjhHwj/0k3hds1Ku3uz9FrrMd6deaItxA0iS3l0VGU5EpdKltxd9L0lIF69PSGNjK
 p0f+sKVVwMibZi/jj5wdChfj//tqs+vwSa66u2xuuAP41IjX3u8RRIEyD8M/ZU9lVH
 QujhisSapa+Cw==
Date: Wed, 22 Jan 2025 15:30:24 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <877c6mdfy0.fsf@HIDDEN>
In-Reply-To: <86v7u72cx7.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <8734hbn31e.fsf@HIDDEN>
 <86v7u72cx7.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 06459e8e7dde6fbf6f0838be3e6380c050367787
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: Andrea Corallo <acorallo@HIDDEN>, monnier@HIDDEN,
 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Cc: monnier@HIDDEN
>> Date: Tue, 21 Jan 2025 23:46:45 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> diff --git a/src/lisp.h b/src/lisp.h
>> index 9c31630cc1a..46e940dad09 100644
>> --- a/src/lisp.h
>> +++ b/src/lisp.h
>> @@ -2226,12 +2226,12 @@ CHAR_TABLE_SET (Lisp_Object ct, int idx, Lisp_Ob=
ject val)
>>        const char *string;
>>        Lisp_Object native;
>>      } intspec;
>> -    Lisp_Object command_modes;
>>      /* Positive values: offset into etc/DOC.  Negative values: one's
>>         complement of index into the native comp unit's vector of
>>         documentation strings.  */
>>      EMACS_INT doc;
>>  #ifdef HAVE_NATIVE_COMP
>> +    Lisp_Object command_modes;
>>      Lisp_Object native_comp_u;
>>      char *native_c_name;
>>      Lisp_Object lambda_list;
>
> IME, having different definitions of data structures under different
> build conditions is a problematic solution: it makes it harder to make

That statement applies to the status quo before the patch just as much
as it does to the new status, though, right?  Lisp_Subr had three
conditional fields before, plus one that's unconditionally compiled in
but only usable if one of the other three is non-nil.  Now it has four
conditional fields, which are unusable if they don't exist because the
compiler won't let you.

> safe changes that don't break some build.  Many/most people don't try

This doesn't; it's impossible ta safely use the command_modes field for
the reasons I explained.

And making it safe without using it at all seems both wasteful and all
but impossible: we'd have to test the code somehow, making up usages of
a field that hasn't been in real use for a long time.

> to build all of the configurations Emacs supports when they make
> changes, so it is easy to write code which references a struct member
> that doesn't exist in some build configuration, and thus break it, and
> miss the fact that build is broken by not trying it.  (It is
> unrealistic to expect everyone who has write access to the repository
> to test-build all the possible configurations Emacs supports as a
> prerequisite for installing a change.)

I agree, but I don't see how that applies here.  Before the patch, if
someone had started using nativecomp-only command_modes, we would have
had very tricky GC/pdumper bugs which would have taken much longer to
resolve than simply removing an unused field.

The new patch does still make it possible for someone using only
nativecomp builds to accidentally use the field for non-nativecomp
subrs.  If someone tried to build that tree without nativecomp, they
would get a compiler error, which is the best we can do to warn them of
this situation, given the constraint that we use the same structure for
nativecomp subrs and primitive ones.

Of course it would be better if we statically asserted that we're
looking at a nativecomp subr before accessing the field, but we've
discussed that and concluded sharing a C structure is a constraint which
I obeyed in this patch.

If you think this field is significant enough to warrant it (it's used
once in comp.c, once in data.c, and three times by pdumper.c; two of the
pdumper usages can be merged because the buggy one would have to be
replaced by the non-buggy one anyway.  The third is an assertion), we
could add accessors, but it's simply not.

> So: do we really need to remove command_modes from the struct in a
> build without native compilation?  What bad things will happen if we

Yes.

> leave it there?  If we would like to be a bit more efficient by
> avoiding a few function calls, like here:

People might use it, and run into the various bugs that have
accumulated.  It's better to remove the unusable field (and there's all
that talk about not wasting two words of staticvec, but wasting 1,000
words is suddenly okay?).

>> --- a/src/pdumper.c
>> +++ b/src/pdumper.c
>> @@ -2992,16 +2992,15 @@ dump_subr (struct dump_context *ctx, const struc=
t Lisp_Subr *subr)
>>                               COLD_OP_NATIVE_SUBR,
>>  =09=09=09     make_lisp_ptr ((void *) subr, Lisp_Vectorlike));
>>        dump_field_lv (ctx, &out, subr, &subr->intspec.native, WEIGHT_NOR=
MAL);
>> -      dump_field_lv (ctx, &out, subr, &subr->command_modes, WEIGHT_NORM=
AL);
>>      }
>>    else
>>      {
>>        dump_field_emacs_ptr (ctx, &out, subr, &subr->symbol_name);
>>        dump_field_emacs_ptr (ctx, &out, subr, &subr->intspec.string);
>> -      dump_field_emacs_ptr (ctx, &out, subr, &subr->command_modes);
>>      }
>
> then it should be okay to #ifdef away those calls when
> !HAVE_NATIVE_COMP, as that doesn't run the risks mentioned above.

That is precisely what I did in the code you cite: the two - lines you
show turned into a single + line behind an #ifdef, which is *precisely*
what we do for the other three fields which are usable in equivalent
circumstances.  Adding a separate #ifdef for two lines that should have
been identical but weren't, a bug that never became relevant only
because the field was unused.

(The bug would have been avoided by some macro-based
check-this-is-a-non-void-pointer code, see the discussion before).

> I also would like to hear from Andrea about this patch.

Absolutely, let's.

Thanks for your comments.

You have convinced me that the .intspec.native union member also
shouldn't exist if we're building without nativecomp.  As we've seen
with Lisp_Subr->doc, using the same field for different purposes is
fragile and leads to bugs.

I won't revise the patch for now as this minor change doesn't really
change things significantly: intspec.native is only set in one place and
read in another one, plus GC/pdumper bookkeeping.  A comment would
suffice, too.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 15:28:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 10:28:27 2025
Received: from localhost ([127.0.0.1]:35905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taceY-0008TY-MD
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 10:28:27 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:52094)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1taceV-0008T5-Bi
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 10:28:24 -0500
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 <eliz@HIDDEN>)
 id 1taceO-0000KU-18; Wed, 22 Jan 2025 10:28:17 -0500
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=XNza+eUd1GZE00VJbPocelsIWM8zXQjTzqV+TwfDzPk=; b=WUgVauJkwuUu
 ZdJkfE41WeIhkIZ7tjbwkUCM6So5JFdzIYT3NiiaylPWdv/Q6P8qMUQt6i67bZuUkhpESw+x+Weu5
 EhxGZ3ht+jTSGA4yZTHJgPYmk1UbkdlgYS0uqyF3jLPQd0eSIzsazGS4Ptvm9MD3AXCXR9Cu+DcH6
 gakAq7eW7ACWDVJTEsok9BMk1ke0JK+0BAKNNnuaxbNcUSLTDmoaEAWqsIvUq3sCoPwIT9zxF0PYE
 jEhcEpqXEHdlNvRwk/DLdYWZSidraRg1zsluaEzxG4FhvH402yWgjsGMapBCTnu0dJDD4Xi2gIlZ9
 O1iGdSbcXzjbi1TGGAPg7g==;
Date: Wed, 22 Jan 2025 17:27:57 +0200
Message-Id: <86jzam3m2q.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87frlbc4dz.fsf@HIDDEN> (message from Pip Cet on Wed, 22
 Jan 2025 14:25:22 +0000)
Subject: Re: bug#75318: Lisp_Subr header and layout
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <86wmen2dj1.fsf@HIDDEN> <87frlbc4dz.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Wed, 22 Jan 2025 14:25:22 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 75318 <at> debbugs.gnu.org, luangruo@HIDDEN, monnier@HIDDEN
> 
> > For example, in the below:
> >
> >>    static union Aligned_Lisp_Subr Swatch_gc_cons_percentage =
> >> -     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) },
> >> -       { .a4 = watch_gc_cons_percentage },
> >> -       4, 4, "watch_gc_cons_percentage", {0}, lisp_h_Qnil}};
> >
> > what is lisp_h_Qnil is relatively easy to understand, whereas the
> > replacement, viz.:
> 
> >> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
> >> +  {{ .header = SUBR_HEADER,						\
> >> +    .function = { .a ## maxargs = fnname },				\
> >> +    .min_args = minargs,						\
> >> +    .max_args = maxargs,						\
> >> +    .symbol_name = lname,						\
> >> +    .intspec = { .string = intspec_value },				\
> >> +    .command_modes = LISPSYM_INITIALLY (Qnil),			\
> >
> > requires one to look up LISPSYM_INITIALLY, which is
> 
> If you're saying that LISPSYM_INITIALLY is bad, I agree completely.

It isn't bad, it's that replacing lisp_h_Qnil with it makes the code
harder to understand (without going crazy with M-.).

As for LISPSYM_INITIALLY, its name is the main source of confusion:
the INITIALLY part all but prevents any attempt to get a clear idea
what the macro does, without actually looking up all the way to the
basics.  Unless on remembers that by heart, of course (I don't).

> > To make the depth of the proverbial rabbit hole at least to some
> > extent smaller here, could we please refrain from defining
> > SUBR_NATIVECOMP_INITIALIZER, and instead include the necessary stuff
> > directly in SUBR_INITIALIZER, with an #ifdef?  Or do you envision
> > enough other users of SUBR_NATIVECOMP_INITIALIZER to justify yet
> > another macro?
> 
> Do you mean
> 
> #ifdef HAVE_NATIVE_COMP
> #define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
>   {{ .header = SUBR_HEADER,						\
>     .function = { .a ## maxargs = fnname },				\
>     .min_args = minargs,						\
>     .max_args = maxargs,						\
>     .symbol_name = lname,						\
>     .intspec = { .string = intspec_value },				\
>     .command_modes = LISPSYM_INITIALLY (Qnil),				\
>     .native_comp_u = LISPSYM_INITIALLY (Qnil),		\
>     .lambda_list = LISPSYM_INITIALLY (Qnil),		\
>     .type = LISPSYM_INITIALLY (Qnil),
>     }}
> #else
> #define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
>   {{ .header = SUBR_HEADER,						\
>     .function = { .a ## maxargs = fnname },				\
>     .min_args = minargs,						\
>     .max_args = maxargs,						\
>     .symbol_name = lname,						\
>     .intspec = { .string = intspec_value },				\
>     }}
> #endif
> 
> (and, I assume, the same thing for SUBR_HEADER?)

No.  I meant to use #ifdef inside the macro.  But if that is
impossible in a C macro, I'd even support making this an inline
function.

Anyway, this is a minor comment, so if it's hard to do better, let's
not go overboard.  I'll survive.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 14:25:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 09:25:38 2025
Received: from localhost ([127.0.0.1]:32773 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tabfm-0004X2-8q
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 09:25:38 -0500
Received: from mail-4316.protonmail.ch ([185.70.43.16]:42667)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tabfi-0004Wh-DO
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 09:25:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737555927; x=1737815127;
 bh=3wqqnyUSxNz7ecR3AryAGXRRo+/8EuiXWihW7/4Wkfs=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=fZQbP8ZiasNHRsOfHmX87GEZWUtwNyvbfB339KNUTbqW9t9K2xs64f9otoezwqDUf
 rp14HKytZlwcmCHcYz5GYdLwbM/HDhmFIKdvDii8fjMA6+UYwx0dPULi+veEvRDruj
 275JP+DDJtZUSy1yhA/Iywed1IDMDH0G3aJYy67e2U+EOT0KVE2qd8kiY1HCh4g2xM
 SoXCmVbTmhId4JTuxvVqLXdUpVh5bQ6DMspXa3l95FkU+vWD4U2Q60JFUO4uCcjydu
 foRq0kTg0vdEspgEEVTasY6gOjIrBbcCr3i7rP5nuGebpFM1HVhQeO/XwWLwyNVFge
 YGEMQN/zQb82w==
Date: Wed, 22 Jan 2025 14:25:22 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <87frlbc4dz.fsf@HIDDEN>
In-Reply-To: <86wmen2dj1.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
 <86wmen2dj1.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 8edae219a316081fa104c4db7f0f54c646449ba7
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Cc: Po Lu <luangruo@HIDDEN>, monnier@HIDDEN
>> Date: Tue, 21 Jan 2025 23:11:13 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> This patch splits up the macros so they're reusable, initializes using
>> LISPSYM_INITIALLY rather than lisp_h_Qnil, ensures that all Lisp_Object
>> fields are initialized, uses explicit field-name initializers, and uses
>> c-mode default indentation (this is incorrect in one place, but it's
>> hardly noticeable).
>
> While I realize that this is a battle lost long ago, I cannot resist
> lamenting the once-simple way many lisp.h macros and inline functions
> were defined, which is all but gone now, replaced by the never-ending
> rabbit hole of macros that call macros that call macros that call...
> Add to this the fact that each macro/inline function has several
> different definitions, whose conditions are sometimes so complicated
> that the only reasonable way to quickly understand what definition a
> particular build uses is to fire up good-old GDB and evaluate the
> macros there, and you get the picture.

I do.  I agree completely.  I don't know how to fix it.

XIL is necessary for CHECK_LISP_OBJECT_TYPE (and there seems to be a
consensus we can't unconditionally enable that one yet), but I don't see
why we can't make an exception for Qnil and make the simple definition
of lisp_h_Qnil apply to this specific symbol in all circumstances:

#define Qnil XIL(0)

If we used that instead, it would make LISPSYM_INITIALLY slightly harder
to find because fewer places would use it.

> For example, in the below:
>
>>    static union Aligned_Lisp_Subr Swatch_gc_cons_percentage =3D
>> -     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) },
>> -       { .a4 =3D watch_gc_cons_percentage },
>> -       4, 4, "watch_gc_cons_percentage", {0}, lisp_h_Qnil}};
>
> what is lisp_h_Qnil is relatively easy to understand, whereas the
> replacement, viz.:

>> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value=
) \
>> +  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
>> +    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
>> +    .min_args =3D minargs,=09=09=09=09=09=09\
>> +    .max_args =3D maxargs,=09=09=09=09=09=09\
>> +    .symbol_name =3D lname,=09=09=09=09=09=09\
>> +    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
>> +    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09\
>
> requires one to look up LISPSYM_INITIALLY, which is

If you're saying that LISPSYM_INITIALLY is bad, I agree completely.

If you're saying a single LISPSYM_INITIALLY in DEFUN, which is
well-documented to the point that users do not have to read the
definition, is worse than three of them in C files, I don't.

>   #define LISPSYM_INITIALLY(name) \
>     TAG_PTR_INITIALLY (Lisp_Symbol, (intptr_t) ((i##name) * sizeof *lisps=
ym))
>
> and then you need to go down the rabbit hole:
>
>   TAG_PTR_INITIALLY
>    =3D> LISP_INITIALLY
>        =3D> LISP_WORD_TAG
>            =3D> VALBITS
>
> Wonderful, right?

I had forgotten how hard it was to get used to this.

I think we should definitely avoid making the situation worse, even if
that means we can't do fun stuff.

> (No, I don't expect you to change anything in your patch, just realize
> the plight.)

Thank you, in any case.

>> +#ifdef HAVE_NATIVE_COMP
>> +#define SUBR_NATIVECOMP_INITIALIZER=09=09=09\
>> +    .native_comp_u =3D LISPSYM_INITIALLY (Qnil),=09=09\
>> +    .lambda_list =3D LISPSYM_INITIALLY (Qnil),=09=09\
>> +    .type =3D LISPSYM_INITIALLY (Qnil),
>> +#else
>> +#define SUBR_NATIVECOMP_INITIALIZER
>> +#endif
>> +
>> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value=
) \
>> +  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
>> +    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
>> +    .min_args =3D minargs,=09=09=09=09=09=09\
>> +    .max_args =3D maxargs,=09=09=09=09=09=09\
>> +    .symbol_name =3D lname,=09=09=09=09=09=09\
>> +    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
>> +    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09=09\
>> +    SUBR_NATIVECOMP_INITIALIZER=09=09=09=09=09=09\
>> +    }}
>> +
>
> To make the depth of the proverbial rabbit hole at least to some
> extent smaller here, could we please refrain from defining
> SUBR_NATIVECOMP_INITIALIZER, and instead include the necessary stuff
> directly in SUBR_INITIALIZER, with an #ifdef?  Or do you envision
> enough other users of SUBR_NATIVECOMP_INITIALIZER to justify yet
> another macro?

Do you mean

#ifdef HAVE_NATIVE_COMP
#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
    .min_args =3D minargs,=09=09=09=09=09=09\
    .max_args =3D maxargs,=09=09=09=09=09=09\
    .symbol_name =3D lname,=09=09=09=09=09=09\
    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09=09\
    .native_comp_u =3D LISPSYM_INITIALLY (Qnil),=09=09\
    .lambda_list =3D LISPSYM_INITIALLY (Qnil),=09=09\
    .type =3D LISPSYM_INITIALLY (Qnil),
    }}
#else
#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
    .min_args =3D minargs,=09=09=09=09=09=09\
    .max_args =3D maxargs,=09=09=09=09=09=09\
    .symbol_name =3D lname,=09=09=09=09=09=09\
    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
    }}
#endif

(and, I assume, the same thing for SUBR_HEADER?)

Avoiding the repetition appears to require a second macro no matter what
I do.

While *I* realize *that* battle was lost long ago, I still think
nativecomp subrs should have had their own PVEC type.

It's too late for that now; let's not revisit a discussion that I
remember as very fair, and which definitely concluded that we'd share
the PVEC type.

I'm thinking (very vaguely; no patch expected in 2025) about proposing
to reduce all Lisp_Objects in the subr object to a simple plist, though,
or a vector if we have to.  I think 32 bytes is a very good size for a
subr to have, and that's header, plist (Lisp_Object so first),
minargs+maxargs+4-byte gap, function pointer union.

It's easier to GC-trace an ordinary PVEC with lisplen=3D1 and restlen=3D2
without worrying about whether it is a subr, I tihnk.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 13:31:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 08:31:17 2025
Received: from localhost ([127.0.0.1]:60892 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taapB-0001eN-4T
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 08:31:17 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:53020)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1taap8-0001e7-MV
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 08:31:15 -0500
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 <eliz@HIDDEN>)
 id 1taap1-000287-Jn; Wed, 22 Jan 2025 08:31:07 -0500
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=IkbaFdu8aCBJwyBzTxCDHIT4cT7pZ4Ij0qmELSDLIEU=; b=XRp7rYJnb0Kd
 53QkgX7QdwWPPPOuK6BQb9AbJ0unanfm78RlLwuHUAeUGAI+LvFdZ47SKV36YBFOQ3GHU30JhlTgp
 wosV+Nyv9gdwb5gPszHpPv8pDbUbIZaw+pZQOSerK+SZ27RAmgonq5Oljv0dE3XzwxDWKizaZ8mgm
 1VWv6XgzTO4Y8/1NHtM0/E1siHW/yHAvy2IBRIX1nOHRaYR5jPr7SAm5bsu6mi0j3GQ1CcYUfHtDK
 drqGXkrRgfC79if34AC614oVaJOxPiGpyLHmah1azK+nMJhlv/1s9C4blk45BJoSJZneT2J0k2FLI
 RO+lDqlFXIYKp0xTS/PNnQ==;
Date: Wed, 22 Jan 2025 15:31:00 +0200
Message-Id: <86v7u72cx7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>,
 Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <8734hbn31e.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#75318: Lisp_Subr header and layout
References: <87seq0j7ix.fsf@HIDDEN> <8734hbn31e.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: monnier@HIDDEN
> Date: Tue, 21 Jan 2025 23:46:45 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> diff --git a/src/lisp.h b/src/lisp.h
> index 9c31630cc1a..46e940dad09 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -2226,12 +2226,12 @@ CHAR_TABLE_SET (Lisp_Object ct, int idx, Lisp_Object val)
>        const char *string;
>        Lisp_Object native;
>      } intspec;
> -    Lisp_Object command_modes;
>      /* Positive values: offset into etc/DOC.  Negative values: one's
>         complement of index into the native comp unit's vector of
>         documentation strings.  */
>      EMACS_INT doc;
>  #ifdef HAVE_NATIVE_COMP
> +    Lisp_Object command_modes;
>      Lisp_Object native_comp_u;
>      char *native_c_name;
>      Lisp_Object lambda_list;

IME, having different definitions of data structures under different
build conditions is a problematic solution: it makes it harder to make
safe changes that don't break some build.  Many/most people don't try
to build all of the configurations Emacs supports when they make
changes, so it is easy to write code which references a struct member
that doesn't exist in some build configuration, and thus break it, and
miss the fact that build is broken by not trying it.  (It is
unrealistic to expect everyone who has write access to the repository
to test-build all the possible configurations Emacs supports as a
prerequisite for installing a change.)

So: do we really need to remove command_modes from the struct in a
build without native compilation?  What bad things will happen if we
leave it there?  If we would like to be a bit more efficient by
avoiding a few function calls, like here:

> --- a/src/pdumper.c
> +++ b/src/pdumper.c
> @@ -2992,16 +2992,15 @@ dump_subr (struct dump_context *ctx, const struct Lisp_Subr *subr)
>                               COLD_OP_NATIVE_SUBR,
>  			     make_lisp_ptr ((void *) subr, Lisp_Vectorlike));
>        dump_field_lv (ctx, &out, subr, &subr->intspec.native, WEIGHT_NORMAL);
> -      dump_field_lv (ctx, &out, subr, &subr->command_modes, WEIGHT_NORMAL);
>      }
>    else
>      {
>        dump_field_emacs_ptr (ctx, &out, subr, &subr->symbol_name);
>        dump_field_emacs_ptr (ctx, &out, subr, &subr->intspec.string);
> -      dump_field_emacs_ptr (ctx, &out, subr, &subr->command_modes);
>      }

then it should be okay to #ifdef away those calls when
!HAVE_NATIVE_COMP, as that doesn't run the risks mentioned above.

I also would like to hear from Andrea about this patch.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 13:18:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 08:18:08 2025
Received: from localhost ([127.0.0.1]:60858 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taacR-0000xU-VL
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 08:18:08 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:35534)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1taacP-0000wv-Bi
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 08:18:06 -0500
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 <eliz@HIDDEN>)
 id 1taacH-0006aD-B5; Wed, 22 Jan 2025 08:17:57 -0500
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=Nfzjn+jsb6GgsenbwBQ5DUxo/GiY/kIY4/e2ncnk6tA=; b=A5nTxy/lG5WZ
 fnlhw91BS1AWfGQWrYpbibHggcxnKHyZV1bXmx9cdIgoclXhS3mz+S5KPQAngum4uRDIO3OfmkR06
 kAQ5iRgfsTKLybgm4PhraGJJgkiT5pbMeJ3PM7sepnQktHucVQFOtsoBMvsq8GTA960Rk09+JZlXo
 CDtJSYwnlQ/LL/8QuEZNANOOay8jZSMNLe1jW8Ql812fJ/KCcQcA8S6hSxiLpHiHJgH4sgUIea7Th
 5dJwbzh0gjxpDbcFARAHvqLu/EmOn5rP+Y6o72lPNji/XVwFflx4TJkB6FZBHzH3Di+WYMEPGRVkx
 PkGmO9aLG2q07whXgKBtag==;
Date: Wed, 22 Jan 2025 15:17:54 +0200
Message-Id: <86wmen2dj1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <878qr3n4on.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#75318: Lisp_Subr header and layout
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: luangruo@HIDDEN, monnier@HIDDEN, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: Po Lu <luangruo@HIDDEN>, monnier@HIDDEN
> Date: Tue, 21 Jan 2025 23:11:13 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> This patch splits up the macros so they're reusable, initializes using
> LISPSYM_INITIALLY rather than lisp_h_Qnil, ensures that all Lisp_Object
> fields are initialized, uses explicit field-name initializers, and uses
> c-mode default indentation (this is incorrect in one place, but it's
> hardly noticeable).

While I realize that this is a battle lost long ago, I cannot resist
lamenting the once-simple way many lisp.h macros and inline functions
were defined, which is all but gone now, replaced by the never-ending
rabbit hole of macros that call macros that call macros that call...
Add to this the fact that each macro/inline function has several
different definitions, whose conditions are sometimes so complicated
that the only reasonable way to quickly understand what definition a
particular build uses is to fire up good-old GDB and evaluate the
macros there, and you get the picture.

For example, in the below:

>    static union Aligned_Lisp_Subr Swatch_gc_cons_percentage =
> -     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) },
> -       { .a4 = watch_gc_cons_percentage },
> -       4, 4, "watch_gc_cons_percentage", {0}, lisp_h_Qnil}};

what is lisp_h_Qnil is relatively easy to understand, whereas the
replacement, viz.:

> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
> +  {{ .header = SUBR_HEADER,						\
> +    .function = { .a ## maxargs = fnname },				\
> +    .min_args = minargs,						\
> +    .max_args = maxargs,						\
> +    .symbol_name = lname,						\
> +    .intspec = { .string = intspec_value },				\
> +    .command_modes = LISPSYM_INITIALLY (Qnil),			\

requires one to look up LISPSYM_INITIALLY, which is

  #define LISPSYM_INITIALLY(name) \
    TAG_PTR_INITIALLY (Lisp_Symbol, (intptr_t) ((i##name) * sizeof *lispsym))

and then you need to go down the rabbit hole:

  TAG_PTR_INITIALLY
   => LISP_INITIALLY
       => LISP_WORD_TAG
           => VALBITS

Wonderful, right?

(No, I don't expect you to change anything in your patch, just realize
the plight.)

> +#ifdef HAVE_NATIVE_COMP
> +#define SUBR_NATIVECOMP_INITIALIZER			\
> +    .native_comp_u = LISPSYM_INITIALLY (Qnil),		\
> +    .lambda_list = LISPSYM_INITIALLY (Qnil),		\
> +    .type = LISPSYM_INITIALLY (Qnil),
> +#else
> +#define SUBR_NATIVECOMP_INITIALIZER
> +#endif
> +
> +#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
> +  {{ .header = SUBR_HEADER,						\
> +    .function = { .a ## maxargs = fnname },				\
> +    .min_args = minargs,						\
> +    .max_args = maxargs,						\
> +    .symbol_name = lname,						\
> +    .intspec = { .string = intspec_value },				\
> +    .command_modes = LISPSYM_INITIALLY (Qnil),				\
> +    SUBR_NATIVECOMP_INITIALIZER						\
> +    }}
> +

To make the depth of the proverbial rabbit hole at least to some
extent smaller here, could we please refrain from defining
SUBR_NATIVECOMP_INITIALIZER, and instead include the necessary stuff
directly in SUBR_INITIALIZER, with an #ifdef?  Or do you envision
enough other users of SUBR_NATIVECOMP_INITIALIZER to justify yet
another macro?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 22 Jan 2025 12:53:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 07:53:51 2025
Received: from localhost ([127.0.0.1]:60790 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taaEw-00087g-EG
	for submit <at> debbugs.gnu.org; Wed, 22 Jan 2025 07:53:50 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26458)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
 id 1taaEo-00087I-Kv
 for 75318 <at> debbugs.gnu.org; Wed, 22 Jan 2025 07:53:46 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2FBFD804E6;
 Wed, 22 Jan 2025 07:53:34 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1737550413;
 bh=SsblUNCXCJ/aOhOCfrX9GJ7iGH+M1xhsvP64LCpnupA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=MjFZvF+3oHAj8XOlXby1YkdlTnnVPVzSpDuYIdOpv+pC+BzZD7rIUx9ASjOMAoAPp
 mf3FH1xipXCx6i8LnB4ojzhl8WW4BEMftjFcm0NNiFNQ7XwtIksTaldlOb71JIU0ck
 i+a5KV2TjbZGnV/+tlDVpOHglcK8Ky0SinycQ4qG13x0aWS5QFn2Gh6roxL8YM5Eu1
 IR8hm5OuFbrAvq+9hT406T5Y4CPBbRCdMPIvkjIe7df58JASy6P95QnBBUq6f2hhVa
 R1IDe7PZRtmEITeNuMegUrl0xE4UURNJZK6r8WDxkONXWAgO8ckyxpGi1Qd+20+i5J
 Sfk5SrNaFAOyQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5942A801F1;
 Wed, 22 Jan 2025 07:53:33 -0500 (EST)
Received: from asado (189.201.173.83.static.wline.lns.sme.cust.swisscom.ch
 [83.173.201.189])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7BEF412084B;
 Wed, 22 Jan 2025 07:53:32 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
In-Reply-To: <878qr3n4on.fsf@HIDDEN> (Pip Cet's message of "Tue, 21
 Jan 2025 23:11:13 +0000")
Message-ID: <jwv8qr3ko5c.fsf-monnier+emacs@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN> <878qr3n4on.fsf@HIDDEN>
Date: Wed, 22 Jan 2025 07:53:31 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75318
Cc: Po Lu <luangruo@HIDDEN>, 75318 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Ideally, we'd turn these three into plain DEFUNs, with docstrings
> indicating they're internal functions.  I'd also like to turn the
> underscores into ordinary dashes in the Lisp function names if we
> do that.

+1
Does anyone know why they're not plain DEFUNs?


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 21 Jan 2025 23:47:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 21 18:47:06 2025
Received: from localhost ([127.0.0.1]:58145 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taNxU-0007B7-IY
	for submit <at> debbugs.gnu.org; Tue, 21 Jan 2025 18:47:05 -0500
Received: from mail-10629.protonmail.ch ([79.135.106.29]:51039)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1taNxR-0007Am-Dy
 for 75318 <at> debbugs.gnu.org; Tue, 21 Jan 2025 18:46:58 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737503209; x=1737762409;
 bh=iBSTTVlETGNVnU1RMP4Ji/0Zcx2eihORR7gVagFt0gY=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=Vw1N8Socgnqh84+8ObpYcylPENbPT3AgXtkUx7DXc10WCJz1b+PkzgSyiIePs93Jb
 cXoK0+y/n/7mopaVHPvofVU5/vpYj/mb/2WeC/x14I9GMY3H11DdCPiDcKb8bBB4gP
 TrT5TFdy28bTUGC1j4jHz461x3zDOI3xtwgTEv6ee8q4755p87ryP2M0KB25ITRYsA
 4XUHc3GnGpxPy+dQTek3G9/JJ/ORvIwVjOli8ZamBoLgGbIaLEsEJYK5y2IveoOUGt
 bQQe4fcNM5g0/NNEfLm6APuZMQLyvopXjBRxDHPQCQIs75gXdkA0UyjTsL0yO0Wxka
 hoOr+bpBvmz3Q==
Date: Tue, 21 Jan 2025 23:46:45 +0000
To: 75318 <at> debbugs.gnu.org
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <8734hbn31e.fsf@HIDDEN>
In-Reply-To: <87seq0j7ix.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 02a3c2d964bb71953116c145a5de9bfa31d76f2c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text ed=
itors\"" <bug-gnu-emacs@HIDDEN> writes:
>
>> I'll prepare patches for those two changes (remove command_modes;
>> correct pvec headers for subrs); not the third (reorder Lisp_Subr
>> fields) because it's a nativecomp change, and there may be a small
>> performance impact.
>
> The second patch fixes Lisp_Subr initialization: the old code set the

This third, small patch moves the command_modes field into the
HAVE_NATIVE_COMP #ifdef.  It adjusts Fcommand_modes to return Qnil for
builtin subrs in the !HAVE_NATIVE_COMP case, and adjusts pdumper, fixing
a latent bug: it used dump_field_emacs_ptr instead of dump_field_lv.  As
that might have been tricky to debug, I briefly confirmed that no
similar bugs remain by compiling with this and --enable-check-lisp-object-t=
ype:

#define CHECK_POINTER(p) ((0) ? (void)(*(p)) : (void) (0))
#define dump_field_emacs_ptr(ctx, out, in_start, in_field) (CHECK_POINTER(*=
(in_field)), dump_field_emacs_ptr(ctx, out, in_start, in_field))

(similarly for other functions using a void * which itself must point to
a pointer, not a Lisp_Object).

This change isn't about saving memory; on my system, it doesn't, since
GCC aligns all Lisp Subrs to 32-byte boundaries on my system.

From 7b1384a7e71f783f3946e7aaad092e8095386387 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Subject: [PATCH] Remove unused command_modes from Lisp_Subr structure
 (bug#75318)

This field isn't marked by the garbage collector in !HAVE_NATIVE_COMP
builds, so using it in those would have led to very tricky bugs.

* src/data.c (Fcommand_modes) [!HAVE_NATIVE_COMP]: Return Qnil for
built-in subrs.
* src/lisp.h (struct Lisp_Subr) [!HAVE_NATIVE_COMP]:
(SUBR_NATIVECOMP_INITIALIZER):
(SUBR_INITIALIZER): Remove command_modes field.
* src/pdumper.c (dump_subr): Don't dump command_modes field unless
necessary.  When it is necessary, use dump_field_lv, not
dump_field_emacs_ptr.
---
 src/data.c    | 2 ++
 src/lisp.h    | 4 ++--
 src/pdumper.c | 3 +--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/data.c b/src/data.c
index dcaa5756ebe..bb7238065f5 100644
--- a/src/data.c
+++ b/src/data.c
@@ -1234,7 +1234,9 @@ DEFUN ("command-modes", Fcommand_modes, Scommand_mode=
s, 1, 1, 0,
=20
   if (SUBRP (fun))
     {
+#ifdef HAVE_NATIVE_COMP
       return XSUBR (fun)->command_modes;
+#endif
     }
   else if (CLOSUREP (fun))
     {
diff --git a/src/lisp.h b/src/lisp.h
index 9c31630cc1a..46e940dad09 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -2226,12 +2226,12 @@ CHAR_TABLE_SET (Lisp_Object ct, int idx, Lisp_Objec=
t val)
       const char *string;
       Lisp_Object native;
     } intspec;
-    Lisp_Object command_modes;
     /* Positive values: offset into etc/DOC.  Negative values: one's
        complement of index into the native comp unit's vector of
        documentation strings.  */
     EMACS_INT doc;
 #ifdef HAVE_NATIVE_COMP
+    Lisp_Object command_modes;
     Lisp_Object native_comp_u;
     char *native_c_name;
     Lisp_Object lambda_list;
@@ -3486,6 +3486,7 @@ #define SUBR_HEADER { .size =3D=09=09=09=09=09=09\
=20
 #ifdef HAVE_NATIVE_COMP
 #define SUBR_NATIVECOMP_INITIALIZER=09=09=09\
+    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09\
     .native_comp_u =3D LISPSYM_INITIALLY (Qnil),=09=09\
     .lambda_list =3D LISPSYM_INITIALLY (Qnil),=09=09\
     .type =3D LISPSYM_INITIALLY (Qnil),
@@ -3500,7 +3501,6 @@ #define SUBR_INITIALIZER(lname, fnname, minargs, maxa=
rgs, intspec_value) \
     .max_args =3D maxargs,=09=09=09=09=09=09\
     .symbol_name =3D lname,=09=09=09=09=09=09\
     .intspec =3D { .string =3D intspec_value },=09=09=09=09\
-    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09=09\
     SUBR_NATIVECOMP_INITIALIZER=09=09=09=09=09=09\
     }}
=20
diff --git a/src/pdumper.c b/src/pdumper.c
index e83c7bcf9a1..64afbdd3065 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2992,16 +2992,15 @@ dump_subr (struct dump_context *ctx, const struct L=
isp_Subr *subr)
                              COLD_OP_NATIVE_SUBR,
 =09=09=09     make_lisp_ptr ((void *) subr, Lisp_Vectorlike));
       dump_field_lv (ctx, &out, subr, &subr->intspec.native, WEIGHT_NORMAL=
);
-      dump_field_lv (ctx, &out, subr, &subr->command_modes, WEIGHT_NORMAL)=
;
     }
   else
     {
       dump_field_emacs_ptr (ctx, &out, subr, &subr->symbol_name);
       dump_field_emacs_ptr (ctx, &out, subr, &subr->intspec.string);
-      dump_field_emacs_ptr (ctx, &out, subr, &subr->command_modes);
     }
   DUMP_FIELD_COPY (&out, subr, doc);
 #ifdef HAVE_NATIVE_COMP
+  dump_field_lv (ctx, &out, subr, &subr->command_modes, WEIGHT_NORMAL);
   dump_field_lv (ctx, &out, subr, &subr->native_comp_u, WEIGHT_NORMAL);
   if (!NILP (subr->native_comp_u))
     dump_field_fixup_later (ctx, &out, subr, &subr->native_c_name);
--=20
2.47.1





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 21 Jan 2025 23:11:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 21 18:11:33 2025
Received: from localhost ([127.0.0.1]:57792 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taNPA-0004yW-Ey
	for submit <at> debbugs.gnu.org; Tue, 21 Jan 2025 18:11:33 -0500
Received: from mail-40133.protonmail.ch ([185.70.40.133]:61317)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1taNP3-0004xg-8W
 for 75318 <at> debbugs.gnu.org; Tue, 21 Jan 2025 18:11:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737501078; x=1737760278;
 bh=r7lL6lZsjyX5sm4osDYdwoIXUViM4I9O/M/XILhp2xQ=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=yI0r6DRz/80Nz4fn7GmARm0lFRJ0yoj1bB39MbP2jwZqjFWK6b910O77unt2V/nHH
 gLZY5Y/puS/bnYLtv3ZkCreB8+W50SSei7wd8FWz/6DO8yYmFRc5ZahHM4OBHhHc6j
 m+EcIb0IYUmA2nK3rApQ0+PIF93jYLqbEd9pR+eQvEhkEKlW0IybAj2hhrpVgirpme
 lftc4GKXeDyenRQCh2+rXHVS5XuzhkusGXFPB+Kkl1NtF8nTwePkwSsBoA09GDwjwt
 FRdLfY/BHBDJyxD295GZaW5KAh8QqrAfuceiYaW0yOB2g0SAsgkU2WRGClbeaDKZSx
 G5iJx2GV6/d2A==
Date: Tue, 21 Jan 2025 23:11:13 +0000
To: 75318 <at> debbugs.gnu.org
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <878qr3n4on.fsf@HIDDEN>
In-Reply-To: <87seq0j7ix.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 79658bdbbc53d5019f0dc56aee8ae6c8aa39d58a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75318
Cc: Po Lu <luangruo@HIDDEN>, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text edit=
ors\"" <bug-gnu-emacs@HIDDEN> writes:

> I'll prepare patches for those two changes (remove command_modes;
> correct pvec headers for subrs); not the third (reorder Lisp_Subr
> fields) because it's a nativecomp change, and there may be a small
> performance impact.

The second patch fixes Lisp_Subr initialization: the old code set the
header to an incorrect value first (PVEC_SUBR was in the type field, but
the PSEUDOVECTOR_FLAG was not set, making it look like a huge ordinary
vector).  Then defsubr wrote to the Lisp_Subr structure to fix that, by
calling XSETPVECTYPE: this didn't affect the type field, but did set the
PSEUDOVECTOR_FLAG.  The size fields always indicated a size of zero.

But three static Lisp_Subr structures weren't defined via defsubr, and
did set the PSEUDOVECTOR_FLAG initially, but otherwise contained
verbatim copies of the DEFUN macro's initialization code.

Ideally, we'd turn these three into plain DEFUNs, with docstrings
indicating they're internal functions.  I'd also like to turn the
underscores into ordinary dashes in the Lisp function names if we do
that.  If we don't, we might at least want to move them to the .subrs
section, or move them out of function scope (function-scope static
variables aren't easy to debug with gdb).

This patch splits up the macros so they're reusable, initializes using
LISPSYM_INITIALLY rather than lisp_h_Qnil, ensures that all Lisp_Object
fields are initialized, uses explicit field-name initializers, and uses
c-mode default indentation (this is incorrect in one place, but it's
hardly noticeable).

This change alone is not sufficient to make the .subrs section read-only.
See store_function_docstring and pdumper.

Like the first one, this second patch fixes things that appear to be
unintended, but that never caused any bugs on the master branch.  The
oddities did cause problems when playing with feature/igc and other GC
stuff, though.

From a67f72e44f5cc9b4af48f0ac3503d3286b0c91a0 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Subject: [PATCH 2/2] Fix Lisp_Subr initialization peculiarities (bug#75318)

* src/lisp.h (SUBR_HEADER, SUBR_INITIALIZER)
(SUBR_NATIVECOMP_INITIALIZER): New macros.
(DEFUN): Use them.  Initialize the header directly to a correct value.
* src/alloc.c (Swatch_gc_cons_threshold, Swatch_gc_cons_percentage):
* src/sfntfont.c (Scompare_font_entities): Use SUBR_INITIALIZER.
* src/lread.c (defsubr): Don't call XSETPVECTYPE to initialize
pseudovector flag.
---
 src/alloc.c    | 10 ++++------
 src/lisp.h     | 29 +++++++++++++++++++++++++----
 src/lread.c    |  1 -
 src/sfntfont.c | 10 +++-------
 4 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index c4e2ff52015..3425f913362 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -8208,16 +8208,14 @@ syms_of_alloc (void)
   Lisp_Object watcher;
=20
   static union Aligned_Lisp_Subr Swatch_gc_cons_threshold =3D
-     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) },
-       { .a4 =3D watch_gc_cons_threshold },
-       4, 4, "watch_gc_cons_threshold", {0}, lisp_h_Qnil}};
+    SUBR_INITIALIZER ("watch_gc_cons_threshold", watch_gc_cons_threshold,
+=09=09      4, 4, NULL);
   XSETSUBR (watcher, &Swatch_gc_cons_threshold.s);
   Fadd_variable_watcher (Qgc_cons_threshold, watcher);
=20
   static union Aligned_Lisp_Subr Swatch_gc_cons_percentage =3D
-     {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) },
-       { .a4 =3D watch_gc_cons_percentage },
-       4, 4, "watch_gc_cons_percentage", {0}, lisp_h_Qnil}};
+    SUBR_INITIALIZER ("watch_gc_cons_percentage", watch_gc_cons_percentage=
,
+=09=09      4, 4, NULL);
   XSETSUBR (watcher, &Swatch_gc_cons_percentage.s);
   Fadd_variable_watcher (Qgc_cons_percentage, watcher);
   DEFSYM (Qalloc, "alloc");
diff --git a/src/lisp.h b/src/lisp.h
index 8b870119315..e9c975b81e8 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3481,15 +3481,36 @@ CHECK_SUBR (Lisp_Object x)
     A null string means call interactively with no arguments.
  `doc' is documentation for the user.  */
=20
+#define SUBR_HEADER { .size =3D=09=09=09=09=09=09\
+      PVECHEADERSIZE (PVEC_SUBR, 0, VECSIZE (union Aligned_Lisp_Subr)) }
+
+#ifdef HAVE_NATIVE_COMP
+#define SUBR_NATIVECOMP_INITIALIZER=09=09=09\
+    .native_comp_u =3D LISPSYM_INITIALLY (Qnil),=09=09\
+    .lambda_list =3D LISPSYM_INITIALLY (Qnil),=09=09\
+    .type =3D LISPSYM_INITIALLY (Qnil),
+#else
+#define SUBR_NATIVECOMP_INITIALIZER
+#endif
+
+#define SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec_value) \
+  {{ .header =3D SUBR_HEADER,=09=09=09=09=09=09\
+    .function =3D { .a ## maxargs =3D fnname },=09=09=09=09\
+    .min_args =3D minargs,=09=09=09=09=09=09\
+    .max_args =3D maxargs,=09=09=09=09=09=09\
+    .symbol_name =3D lname,=09=09=09=09=09=09\
+    .intspec =3D { .string =3D intspec_value },=09=09=09=09\
+    .command_modes =3D LISPSYM_INITIALLY (Qnil),=09=09=09=09\
+    SUBR_NATIVECOMP_INITIALIZER=09=09=09=09=09=09\
+    }}
+
 /* This version of DEFUN declares a function prototype with the right
    arguments, so we can catch errors with maxargs at compile-time.  */
 #define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc) \
   SUBR_SECTION_ATTRIBUTE                                            \
   static union Aligned_Lisp_Subr sname =3D                            \
-     {{{ PVEC_SUBR << PSEUDOVECTOR_AREA_BITS },=09=09=09    \
-       { .a ## maxargs =3D fnname },=09=09=09=09    \
-       minargs, maxargs, lname, {intspec}, lisp_h_Qnil}};=09    \
-   Lisp_Object fnname
+    SUBR_INITIALIZER(lname, fnname, minargs, maxargs, intspec); \
+    Lisp_Object fnname
=20
 /* defsubr (Sname);
    is how we define the symbol for function `name' at start-up time.  */
diff --git a/src/lread.c b/src/lread.c
index e5d1ba0e6bb..279d384eed6 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -5475,7 +5475,6 @@ defsubr (union Aligned_Lisp_Subr *aname)
   struct Lisp_Subr *sname =3D &aname->s;
   Lisp_Object sym, tem;
   sym =3D intern_c_string (sname->symbol_name);
-  XSETPVECTYPE (sname, PVEC_SUBR);
   XSETSUBR (tem, sname);
   set_symbol_function (sym, tem);
 #ifdef HAVE_NATIVE_COMP
diff --git a/src/sfntfont.c b/src/sfntfont.c
index 5752ff81c1c..b7a8b7c2671 100644
--- a/src/sfntfont.c
+++ b/src/sfntfont.c
@@ -1985,13 +1985,9 @@ sfntfont_compare_font_entities (Lisp_Object a, Lisp_=
Object b)
    fields are set within the first than in the second.  */
=20
 static union Aligned_Lisp_Subr Scompare_font_entities =3D
-  {
-    {
-      { PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS), },
-      { .a2 =3D sfntfont_compare_font_entities, },
-      2, 2, "sfntfont_compare_font_entities", {0}, lisp_h_Qnil,
-    },
-  };
+  SUBR_INITIALIZER ("sfntfont_compare_font_entities",
+=09=09    sfntfont_compare_font_entities,
+=09=09    2, 2, NULL);
=20
 /* Return a list of font-entities matching the specified
    FONT_SPEC.  */
--=20
2.47.1





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at 75318 <at> debbugs.gnu.org:


Received: (at 75318) by debbugs.gnu.org; 21 Jan 2025 13:05:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 21 08:05:06 2025
Received: from localhost ([127.0.0.1]:53656 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1taDwH-0006Jj-Fx
	for submit <at> debbugs.gnu.org; Tue, 21 Jan 2025 08:05:05 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22]:50235)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1taDwD-0006IU-Mb
 for 75318 <at> debbugs.gnu.org; Tue, 21 Jan 2025 08:05:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737464694; x=1737723894;
 bh=sYX47Fqx/HXpOdg01AFVA6ClIouR+5+wSJ6BWdiopDo=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=V9Cq6rn4cTmQViro+1UniSc9mbkxGg2xu//rMGKvcyA0VgThVd2w8GaKLQwSAiBO6
 LT/N3V9OyjR1EiMOVV92bIie2IEoS0SYgdAbptzCk6uaOyMpb+1j3oe4BjzvL8HTgr
 PBvW9688tdN/aluyfWjIuZcQl56x5p9YQ5I9NKcLBbAJsjBp+b+gN6vFAp9PAViLuN
 E2CKXZbJSKavRAvnWyjc+sRx8vta5Wi1KjxHN7HF5HotZI0RHXwlfPdkDNKQYUrza9
 wrnfBhuu3wh7FcKYTvHpXaXyXTwkVNcEjIdqiswiz4p+QnRGoxvkjd3iNaVEixXoiH
 OJncP/cueHX2w==
Date: Tue, 21 Jan 2025 13:04:48 +0000
To: 75318 <at> debbugs.gnu.org, monnier@HIDDEN
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75318: Lisp_Subr header and layout
Message-ID: <87y0z4jp1z.fsf@HIDDEN>
In-Reply-To: <87seq0j7ix.fsf@HIDDEN>
References: <87seq0j7ix.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 022a2f538076537b90e069c1937f25c632a11c7c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 75318
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text edit=
ors\"" <bug-gnu-emacs@HIDDEN> writes:

> I'll prepare patches for those two changes (remove command_modes;
> correct pvec headers for subrs); not the third (reorder Lisp_Subr
> fields) because it's a nativecomp change, and there may be a small
> performance impact.

The first patch is a simple bug fix. Is this okay?

PVECHEADERSIZE uses "lispsize" and "restsize", but allocate_pseudovector
uses "memlen" and "lisplen".  That's confusing.  Someone was confused,
the header value was wrong but it never caused any trouble.  Still, it's
good to fix this, and it caused trouble for feature/igc.

Ideally, we would fix the confusing situation.  My suggestion is to
always pass all three sizes.  Please let me know if that's desirable.

From 08fd00deb5d4d7ea73d2959577d2b4ab9855f1c2 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Subject: [PATCH 1/2] Correct PVEC header for main_thread (bug#75318)

* src/thread.c (main_thread): Pass correct restsize to PVECHEADERSIZE.
---
 src/thread.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/thread.c b/src/thread.c
index 5610f8be0dd..5539fae15ab 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -50,7 +50,9 @@ static_assert (GCALIGNED (union aligned_thread_state));
       .header.size =3D PVECHEADERSIZE (PVEC_THREAD,
 =09=09=09=09     PSEUDOVECSIZE (struct thread_state,
 =09=09=09=09=09=09    event_object),
-=09=09=09=09     VECSIZE (struct thread_state)),
+=09=09=09=09     VECSIZE (struct thread_state) -
+=09=09=09=09     PSEUDOVECSIZE (struct thread_state,
+=09=09=09=09=09=09    event_object)),
       .m_last_thing_searched =3D LISPSYM_INITIALLY (Qnil),
       .m_saved_last_thing_searched =3D LISPSYM_INITIALLY (Qnil),
       .name =3D LISPSYM_INITIALLY (Qnil),
--=20
2.47.1






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 Jan 2025 14:30:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 09:30:51 2025
Received: from localhost ([127.0.0.1]:50173 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tTihN-0002Nk-NL
	for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 09:30:50 -0500
Received: from lists.gnu.org ([2001:470:142::17]:58564)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tTihA-0002NI-TH
 for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 09:30:44 -0500
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 <pipcet@HIDDEN>)
 id 1tTigp-00065j-6u
 for bug-gnu-emacs@HIDDEN; Fri, 03 Jan 2025 09:30:25 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <pipcet@HIDDEN>)
 id 1tTigh-0002vW-58
 for bug-gnu-emacs@HIDDEN; Fri, 03 Jan 2025 09:30:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1735914603; x=1736173803;
 bh=DzuwK/hovEC1RFUTGym5K68YfDpYIInVMT+g35cS6Xs=;
 h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
 List-Unsubscribe:List-Unsubscribe-Post;
 b=uuI6oqszn1n3rkAjP0QFBD57ShuCz9mKYf88TUeo+v9XPFZAhH4avtzo/v7JVnLZL
 6oQnG82yrtcSuL18/0fYMxM/aDOQUw6SSqZ0asXmspXv1VjPjPxv9OsXd7uuKwpbIR
 BmeNjI2LhFj2KojbFBnMrAlvJGaIH7QFn/tC3eb9H3F+bZm2GkqNG21+yBiaIpo0dg
 8l1fn8waDDxen18QKruzbjv8LTAHDi3Oo/skDNfw6PLjGnY/pzNaThG5AmzmBac7p8
 BBzXTpxPdo+LliQiafaRFqbTtpctTloV2ganl2vyD+vKEifKzD955tMPwJJNWrDtOF
 04kkufY6nNVoA==
Date: Fri, 03 Jan 2025 14:29:58 +0000
To: bug-gnu-emacs@HIDDEN, Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Lisp_Subr header and layout
Message-ID: <87seq0j7ix.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: fadd83e8793a19ce89b912fc40ec9a24b3686a3d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@HIDDEN;
 helo=mail-4322.protonmail.ch
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Lisp_Subr::command_modes aren't marked by GC; the vectorlike_header of
Lisp_Subr is often incorrect; Lisp_Subr fields don't follow the usual
order

This is not an acute bug, but it's problematic code which might cause a
bug if something changes.

struct Lisp_Subr contains a "Lisp_Object command_modes" field, whether
or not Emacs is built with native-comp support.  It's only marked by GC
if Emacs is built with native-comp support.  Putting arbitrary values in
there would cause crashes.

Right now, command_modes is always Qnil in non-native-comp builds, so
this isn't a problem as nil doesn't need to be marked explicitly by GC;
it does, however, waste some space (5 KB on 32-bit machines).

I think making the existence of the command_modes field depend on
nativecomp would be the best solution; if we want to use a command_modes
field for non-nativecomp builds, in the future, we have to change the GC
marking code and the pdumper code, but I really don't see the point of
allocating and GC-marking a field that we know is always nil on the off
chance it might be useful in the future.

After this change, struct Lisp_Subr contains no Lisp_Object fields, and
if we want to add one (most likely because ::doc should be a Lisp_Object
rather than an EMACS_INT) again, we should consider making it an
ordinary PVEC, with the Lisp_Object fields first and the POD C data at
the end.  This would eventually allow us to remove the special-casing of
subrs in the GC code, but this would also require us to use the expected
pvec header word value for built-in subrs; right now, we don't.

I'll prepare patches for those two changes (remove command_modes;
correct pvec headers for subrs); not the third (reorder Lisp_Subr
fields) because it's a nativecomp change, and there may be a small
performance impact.

Pip





Acknowledgement sent to Pip Cet <pipcet@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#75318; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 23 Jan 2025 12:15:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.