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#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sat, 04 Jan 2025 20:19:33 +0200 Message-ID: <86ttaebfwq.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.fsf@gnu.org> <87a5c6j0qn.fsf@protonmail.com> <86jzbad735.fsf@gnu.org> <877c7aha9n.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4806"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 19:20:27 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 1tU8l8-00016t-Un for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 19:20:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU8kt-0004bl-88; Sat, 04 Jan 2025 13:20:13 -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 1tU8kl-0004ZP-O9 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 13:20: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 1tU8kl-0004qy-E2 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 13:20:03 -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=LV1mQBE6XklXeddvt52jFqtlgQVMIMhMFV/+Scu3yuc=; b=W9zuNP/oWwNQvpraQ3tDbC3Q6Q7Z8hjAm+vfJ33J3k2eQyglO69jTgNXO4jhKtC8VcoS27jV4x2GHYCM0CHhSOEdrCXv12nJeZMjY6WA9NTNF2/oBpy9YgbkIR/4C+IGJX+k/qgX5sIw5vZPm5VBqgCbka0peJ7WWYb3bFRjsJ4nba9HcbX+saXCpcs6Hz2+gm7XlYLV/Cw1bbBFzn/KNSoQ1iP4G+W18Iem29jq3CICyDM1z1n8JYJcXDNaFzS2vF8eGzPjOCXDiEf6bYfp+r5RN8lY2WvJSPQRU0EWK0OLpuYrN0GzclG3u8UhPYCChCa0QDpiqLgKmvHLBrXUVw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU8kk-0005hC-Pi for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 13:20:02 -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, 04 Jan 2025 18:20: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.173601478521859 (code B ref 75322); Sat, 04 Jan 2025 18:20:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 18:19:45 +0000 Original-Received: from localhost ([127.0.0.1]:57274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU8kS-0005gV-G7 for submit@debbugs.gnu.org; Sat, 04 Jan 2025 13:19:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49756) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU8kQ-0005gH-GW for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 13:19:43 -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 1tU8kJ-0004oQ-RX; Sat, 04 Jan 2025 13:19:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=LV1mQBE6XklXeddvt52jFqtlgQVMIMhMFV/+Scu3yuc=; b=reQ7gkUm8MM0xy+PlChH jvc5oxToQ/sJWSMCw5lo88R33W8btcFhtXAIpvH0cEhTnA3D3VKh1IEoCIcgRZm59TZ250MJ08lQK ngGJrhfow9PpEUcL1FrAk47OVe1KKF9W/aqd0zghW0LYZ1p2j95ASS4N2XjQEyPX8hSuJQQ/GTTBk Fn4SqNAVXImrscaEUPdbWY9lKk3byIIIEOC9Mrh/GWTXh7vQDb8H2pQLchbAG73uXJHkCq+9LpUro Fj9TZ+jN1ibjQLQ8JL5JJKjFeeui+tfzgN57osphYAoPUusBDxwnb8QxwtzDDuf7o+vSvfMeczwhI ZaqUGvpNv0TklQ==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sat, 04 Jan 2025 16:34:15 +0100) 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:298444 Archived-At: > From: Gerd Möllmann > Cc: Eli Zaretskii , 75322@debbugs.gnu.org > Date: Sat, 04 Jan 2025 16:34:15 +0100 > > I'm entering a state of confusion again, as usual in this discussion. > Can we _pretty please_ just do the xstrdup thing, and forget about it? We could do that, but what does this mean for our protocol of using data from Lisp objects in libc and system calls? Does it mean we cannot use SAFE_ALLOCA? Does it mean we must always xstrdup every string and xmalloc every other object before calling some system API? Are Lisp strings safe when GC can strike, or aren't they? What about Lisp vectors? Etc. etc. We must figure out what are the safe and sound rules for doing this with MPS, like we had with the old GC. Otherwise, we will be unable to write correct and sound code, and we'll be unable to audit code written by others. Right now, it doesn't seem to me like we have a clear idea of what's permitted and what's unsafe. We are still arguing whether GC moves Lisp strings and what exactly does that mean. We still don't understand well enough what, if anything, are the problems with SAFE_ALLOCA and its ilk. We just established that ENCODE_FILE and ENCODE_SYSTEM can trigger GC, and didn't yet review the affected code. And there are many more places and calls to consider (e.g., do you know that redisplay could trigger GC when it calls character composition?). If we don't consider this stuff, if we just "do the xstrdup thing and forget about it", how can we continue cleaning up the igc branch and making its code more stable and reliable? It doesn't sound wise to me.