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: Sun, 05 Jan 2025 21:07:26 +0200 Message-ID: <86h66d6pw1.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> <86msg56to8.fsf@gnu.org> 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="11867"; 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 Sun Jan 05 20:08:19 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 1tUVyz-0002ow-Ab for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 20:08:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUVyl-0002eH-G3; Sun, 05 Jan 2025 14:08: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 1tUVyk-0002dx-B7 for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 14:08: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 1tUVyk-0006tJ-2P for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 14:08: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=DTqbswfqr93AvLdai1CutRWu5QJ1AnORac4HqnCHdD8=; b=c293JVQGquu9wSx7NHSM9nq3byA2rNI89rxgdYoavFtmfKl7myqvJWQHZJTJi/E8XSJh0PfWy7+EX/HDPbvLQOEMbxwH0XFNsw5FQLzW7Tx1d59SH1ZGO5lOKsuSe+ZiW/M/fwae5rvvUZiI7gwx6p8Vj1QmGsFtbgvt0nuG6Oj0Am7yKIfDJ7lwqQjnCxLX++ev0rIselgb6iKgBqJw8Qna/InXrO3YxZ8crZV9Y3vwcpjHvZyjflH7/7rtOvri1aXcPUdV7xsyqKuy5dNhPQtQeixIEzBjY5uPvfvjDbh8k8GTD2lxNMqe4psPsDB/z3M23i6VZO0ISUWn0OBx2Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUVyj-0003oT-Se for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 14:08: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: Sun, 05 Jan 2025 19:08:01 +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.173610405714616 (code B ref 75322); Sun, 05 Jan 2025 19:08:01 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 19:07:37 +0000 Original-Received: from localhost ([127.0.0.1]:35250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUVyK-0003nf-Ub for submit@debbugs.gnu.org; Sun, 05 Jan 2025 14:07:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51102) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUVyJ-0003nS-P8 for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 14:07:36 -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 1tUVyD-0006of-Fv; Sun, 05 Jan 2025 14:07:29 -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=DTqbswfqr93AvLdai1CutRWu5QJ1AnORac4HqnCHdD8=; b=diPn6qIBy3val9fkjbOp oj0siuL1DsIV0de6iI57SSIDwAOO0OppMbKc2Bg/GlQdDIGZwxwB6ESfQdule/P1A26GpFNq7i8ax XvgdpbrAHHaaNhldXDjNjVwudBRGLFRSNaYPtU+8J6setbgUEqRyEr0WKMsCyKk2gWBL0vQK/3ffM 72FfpD2aYba4cJE/ltZOnzuKsMPY+j5vf/lq6Zq2iEgKGFi6N58xPYIT633B/K3Fxf2miqCm/FgKt 0wwuzeqYwoD7+U3QsW9lmPVz9u3xLSttMAM4ffCilHlEk3Zl++hD5YZfmXrrSARRoGB630pqHI2hn RMHbcSqiCb+0IQ==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sun, 05 Jan 2025 19:17:37 +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:298595 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org > Date: Sun, 05 Jan 2025 19:17:37 +0100 > > Eli Zaretskii writes: > > > OK, but in most, if not all of these cases, the objects are referenced > > from the stack. For example, in the above fragment, the args[] array > > is on the stack. Right? > > That args is a parameter > > call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, > > So just from this I see only args itself on the stack, not args[0], > args[1] and so on. I would have to look at all callers to determine > that. Not good enough in my book. So what, we will now need to copy every args[] into a Lisp vector created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in each and every function that gets the args[] array, all the way down to where the array is finally used (because usually we have 3 or 4 nested levels that pass args[] to one another)? That's insane! > > What does it mean in detail "the object may move"? A Lisp object is a > > tagged pointer. Do you mean the pointer should no point to a > > different address, i.e. the value of a Lisp object as a number should > > change to still be valid? > > Exactly. Unless an ambiguous reference prevents the copying that can > happen. How can we possibly make sure this works reliably and safely?? For each variable we have in every function, we will need to analyze whether the variable is . an automatic variable . a static variable that is protected by someone . a global variable that is protected by someone . a result of dereferencing a pointer that is somehow protected etc. etc., where "protected by someone" means that it is a descendant of some staticpro, or of some root, or... And if we cannot prove to ourselves that one of the above happens, then we'd need to force a copy of the variable to be on the stack? Does this sound practical? If this is the price of using MPS, and I'm not missing something obvious, then it sounds like we should run away from MPS, fast. Because we will sooner or later have to rewrite every single line of code we ever wrote.