From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 09:04:06 +0000 Message-ID: <877c79eipq.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <87a5c6j0qn.fsf@protonmail.com> <86jzbad735.fsf@gnu.org> <877c7aha9n.fsf@protonmail.com> <86y0zqbgot.fsf@gnu.org> <87ttaee5qp.fsf@protonmail.com> <86a5c6b9sb.fsf@gnu.org> <87ikque0xp.fsf@protonmail.com> <864j2dacuz.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6221"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 75322@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 10:05:21 2025 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 1tUMZT-0001Oj-0Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 10:05:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUMZE-0005WR-5o; Sun, 05 Jan 2025 04:05:04 -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 1tUMZD-0005Vp-1t for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:05:03 -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 1tUMZC-00061P-PL for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:05:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=mNz3oG7ljXndl4qoS5pQuUwDPovF5sWWzU3Qzqh1Ymk=; b=jxggVeb12gFrtIV+H8uTllVyUOeBvu35LwAyywNwhRYVVs+kl7t8oHy4FaaEdXhqx3hhixh5QULD5QMw62TeqBghZNI8cY7ZlGebkDR7P4TithcjB1NxdRnM6bhArxpY3K2hp6xOTDnfSR+POBfg0vCfrHVjhC187CCV0LUnc14JxScRd6H18roDRAWrOFab5i1nGSJdUK0NDI7fnFwEEugVs47HWr8tAjHEFUCCBnLimBGASkdoAiL3hAyfbhcVJwFqgFbLj2FOaPQIiW14Q0XlAI7RvkSlGXWXBY4Rs96bqADgWxd16j+lUbMoCIn6RHQGbFuNLKoRjOAOeIRYXA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUMZC-0005u0-AK for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 09:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.173606786322626 (code B ref 75322); Sun, 05 Jan 2025 09:05:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 09:04:23 +0000 Original-Received: from localhost ([127.0.0.1]:59824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUMYY-0005ss-Ld for submit@debbugs.gnu.org; Sun, 05 Jan 2025 04:04:23 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]:21983) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUMYV-0005sb-Kd for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 04:04:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736067852; x=1736327052; bh=mNz3oG7ljXndl4qoS5pQuUwDPovF5sWWzU3Qzqh1Ymk=; 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=Mf18hImFfM7co7TOWtsR3q1BXiN8vx1sLYh4C0t02zqUlsxYbr1Q+YnSUEpJvbjEF n6CE5El9YMIlSc+tYCyytv2Za5BJMye4M3fLA2HQcc8A7/KweO29WbNY1bRWB77eMM qb4gRV6zDhkdOcMXbI83Q3wI2Cn68gtMH9LFgO3x39uLhWtNNWJEBgF+MVgkm1h6b4 7gWXpWm8LJnq589jdKGudbbDJM+ebu6zaQ3qK77zsI6Moh0S/AcrkwETMOdEGdYuYK XYiDI7LqDoqwyJD2ZzEA9xUAkfi5pcaz6FeIFUWwGt3EIWSzmDYAiuXT1a3C7cNUmc XWBK6Et58K50g== In-Reply-To: <864j2dacuz.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a78cda21f82877d299e5c14a5023df3114712291 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:298521 Archived-At: "Eli Zaretskii" writes: > we should be able to use without restrictions static variables whose > values are Lisp strings. Without staticpro? That makes no sense whatsoever to me. It's not true for either garbage collector. Do you expect MPS to scan the entire data/bss segment ambiguously? >> Which might be in a register and not survive until GC is triggered. > > A Lisp_Object variable will survive. Its pointer will be updated if > needed to point to the new location of the data. Thus, using the MPS never changes the value of an automatic variable. > Lisp_Object variable is always safe, but the pointer to its data must > be updated after a potential GC. > >> >> > The below is indeed unsafe: >> >> > >> >> > char *p =3D SDATA (unmarked); >> >> > ... trigger GC here ... >> >> > puts (p); >> >> >> >> Right now, that's safe for MPS, but not for the old GC, correct? >> > >> > If GC moves string data, then it is not safe, period. Does MPS move >> > string data? >> >> MPS does not move string data if there is a stack variable pointing to >> it. It does in other cases. This is why it's safe for MPS. The old >> GC, IIUC, is less forgiving. > > The conclusion is that the above is NOT safe, because in some cases > the data could move. Which was what I said from the get-go. The conclusion is incorrect. The code is safe if MPS is in use, and we rely on that. The idea behind MPS is that you write code as above, which is safe when MPS is in use, rather than attempting to avoid GC, which is fragile at best (see call_process) and impossible in multi-threaded systems. We have to avoid the old GC in the !HAVE_MPS build, but with the MPS collector, there is no need (and no way) to avoid GC here. You seem to fundamentally disagree with me about how MPS works. We need to resolve that difference one way or another before we can continue any GC-related discussions. Pip