From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74966: 31.0.50; Crash report (using igc on macOS) Date: Sat, 21 Dec 2024 08:47:39 +0200 Message-ID: <864j2xa5x0.fsf@gnu.org> References: <86a5cqkc2g.fsf@gnu.org> <86o716ah09.fsf@gnu.org> <87ikrejok5.fsf@protonmail.com> <86cyhm9m9a.fsf@gnu.org> <87seqihyex.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, spd@toadstyle.org, acorallo@gnu.org, monnier@iro.umontreal.ca, 74966@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 21 07:48:21 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tOtHh-0008s7-DX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Dec 2024 07:48:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOtHP-0001uq-IT; Sat, 21 Dec 2024 01:48:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOtHO-0001ud-AP for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 01:48:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOtHO-0005SV-29 for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 01:48:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=62MxWabVuQ+8fQTCO3GYcFpw+T+36wfSG6W5+QcbPZc=; b=eh973eREfgMmzG0dkh07RcIqfpGBPhKkMR+YKyS4fRGslFDlyfi4GElGsZg8NS6Q1ViUUHpbjBKREf3e/79ilrNoPpRlFcgxWeyYq8EQ01yiM7GZlhfVsrguvryx2a48fGnWcNlZmY63vJblipTsaCSBTGWjoh+L1SRBqpYW02kHbRnTW4DLcIwCc8gaokYguoTTlHYvfp0XOJkRVZ6udSNAy4LD1OKy7nMUu3VACnAaM+KdATouZ3D3K2OKWmAfrwRN0YGJAQ8ltkrEjruyG5Mcf1wIKPV2PjrnYcAgaWlIiT/C9Xz5KiwLra4eRrVI+L4RjfSj4FHbidj6Wk42qw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tOtHN-0007x3-T6 for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2024 01:48:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Dec 2024 06:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74966 X-GNU-PR-Package: emacs Original-Received: via spool by 74966-submit@debbugs.gnu.org id=B74966.173476367230549 (code B ref 74966); Sat, 21 Dec 2024 06:48:01 +0000 Original-Received: (at 74966) by debbugs.gnu.org; 21 Dec 2024 06:47:52 +0000 Original-Received: from localhost ([127.0.0.1]:44997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tOtHE-0007we-5H for submit@debbugs.gnu.org; Sat, 21 Dec 2024 01:47:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tOtHB-0007wO-Nu for 74966@debbugs.gnu.org; Sat, 21 Dec 2024 01:47:50 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOtH4-0005Qy-6J; Sat, 21 Dec 2024 01:47:42 -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=62MxWabVuQ+8fQTCO3GYcFpw+T+36wfSG6W5+QcbPZc=; b=KeyYlxIxDE3i z5oV3A7NA9A55WHjYkdMeJc81ldoWD9sCaBl8fThu87SDf7DmFLpu3ys6qYDbUVdIvlhJ5aR5CUXM /AdtAe+ZywLyGEfbibXAOvbIwHarKtv13vlgcamdLOBZYbs4ORgj9QPV2e5xzMlD37wLwL4pcN7H3 n0LjWSCOcUeXjeVjCHTXT2pQXf8wTz1mSt7o4UZeIrIn5H8Y7JdqmIA5nrBu6wmmwQ5BB/M/Qmtzx to6YEPqT7+NruL/Dipzj5qp2qhnOMaSoUczz/ZAWrTUL4E17bV+iTisEfVOHHW9kLSKCYcuXjiRmI drjwASxKSokzv7PWkx50cA==; In-Reply-To: <87seqihyex.fsf@protonmail.com> (message from Pip Cet on Fri, 20 Dec 2024 20:50:56 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297486 Archived-At: > Date: Fri, 20 Dec 2024 20:50:56 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, spd@toadstyle.org, acorallo@gnu.org, monnier@iro.umontreal.ca, 74966@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > TBH, I'd be much happier without splitting 'doc' into two members. > > Isn't it possible to avoid overwriting 'doc', thus avoiding the crash, > > without splitting the member in two? > > Absolutely. That'd cause wrong docstrings for some symbols Can you elaborate on that? When and how could that happen? > but reduce > the risk of code not compiling anymore. There is no risk of unvetted > code compiling and accessing the doc field, because it's been renamed, > but that does require, of course, to consider the changes in the patch > as "vetted"; furthermore, if there is a compilation error in some code > I've missed, we need to be careful not to fix it without checking that > code, too. I didn't have in mind problems that will be caught by the compiler -- these are easy to find and fix, even if it takes some time because some code is only compiled on a certain rarely-used platform or configuration. > > DOC handling in Emacs is extremely complex and has many subtle > > aspects. Experience teaches us that bugs in this area sometimes take > > years to report and fix. Splitting a member into two risks > > introducing bugs because we might use the wrong member in some > > situation(s). > > I don't understand this specific objection. If we rename "doc" to > "doc_offset", as I've proposed, we're automatically looking at all code > which makes use of the new field, because code using the old name no > longer compiles. Yes, sure. If we just rename a single member and all of its references, there's no risk whatsoever. I had something else in mind. If we split the 'doc' member in two, some code which used 'doc' will need to use 'doc_index', and some code will need to use 'doc_offset'. The risk is in using the wrong one, because the intent of the original code (i.e., whether it interprets 'doc' as an index or as an offset) was not completely understood. Moreover, it is possible that in some places we'd need to set the value of one of these two members from the value of the other, because the original code relied on the fact that there's just one member whose value is sometimes interpreted as this and sometimes as that. > > The test suite's coverage of doc.c and features related > > to doc strings is still rudimentary, so we cannot be sure any such > > bugs will be caught in time by the tests. Which is why I hope we can > > avoid splitting this member in two. > > I agree that the docfile hack in general is very hairy territory. It > might be safer to simply accept the wrong docstrings for now, and Gerd's > patch does that, IIUC. Can we just apply that for now and add a FIXME? Maybe, but I'd like first to understand better the "wrong docstrings" situations. Thanks.