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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.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
Pip Cet <pipcet@HIDDEN>
:bug-gnu-emacs@HIDDEN
.
Full text available.bug-gnu-emacs@HIDDEN
:bug#75318
; Package emacs
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.