From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 21:04:56 +0100 Message-ID: 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> <86h66d6pw1.fsf@gnu.org> 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="9604"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.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 21:06:31 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 1tUWtL-0002LJ-Br for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 21:06:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUWt4-0008Kz-Jf; Sun, 05 Jan 2025 15:06:14 -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 1tUWt3-0008Kq-F7 for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 15:06:13 -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 1tUWst-0007G6-1y for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 15:06:13 -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:Date:References:In-Reply-To:From:To:Subject; bh=F+pZ3BGIF5n/uoMpYqXc46Z41ISv1vbtZXFO/MXbhWs=; b=AhTfXl7XX+2kG/O6c4Xd+lxvZf+ug+Mz1ZzKIi613+tXE6UYNJwGCKAEHe7MX8kXfABv5aNKc9WXTpMmJ48jbTz9f+b2FVBeDILF8m7tiC5CZHc8KwDGbKsZmC13l7cS3+RSfu8lLIQfTe0nXEU/QHyrpJEWbZ0/AupZmGiDqxA700r+x9+/ZP98q1NUH6JKn7YJfhnvkm7ASLlKobL0rrqdCNb6swuLgVzP+8KX+QE6wfxWazUwhQTXuJ1BVun9CC9DpIbXhWyKri7PSsVxFymqvj4UJiR1kcmxX8GsqEAWabZGCFw0CZxJOH5TaJoutmMduUwZ1FtXa/NQkwFKog==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUWss-00070n-IC for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 15:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 20:06: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.173610750826747 (code B ref 75322); Sun, 05 Jan 2025 20:06:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 20:05:08 +0000 Original-Received: from localhost ([127.0.0.1]:35365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUWs0-0006wY-9Y for submit@debbugs.gnu.org; Sun, 05 Jan 2025 15:05:08 -0500 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:59523) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUWrx-0006sh-Le for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 15:05:06 -0500 Original-Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3862df95f92so5979622f8f.2 for <75322@debbugs.gnu.org>; Sun, 05 Jan 2025 12:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736107499; x=1736712299; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=F+pZ3BGIF5n/uoMpYqXc46Z41ISv1vbtZXFO/MXbhWs=; b=DqeFH/0arfE0hXC5ARFIfD4HJVsbR2obog8aVeP2TGa+hNAFfMnyRtgJ8N/7/JZHwk VvIHSSVWXqJZ5kkHh0AtWpURtJhMl95CcMbReR5jTggjJqfmP/GbaUKW9zuXMDvr55te zwxXYPtlOXrx1PupJcAbB8+9vhBnZOl/HhHpFilGyBAGd8Eo6i5Awx3feuOjVgL7W/6M JWzTCcY3WGVy/YRuCHlKEQeiiw21qrv1++GJnPyugDxJxUp0XAICmNDCAY5Pu78DAazn MeIn71V2FuHTvetNf8pEZ7WZPiZHllY1762EQeM0GRJphaHFG+JOQegKLw0d5S4im9fl nKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736107499; x=1736712299; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=F+pZ3BGIF5n/uoMpYqXc46Z41ISv1vbtZXFO/MXbhWs=; b=L3tLNhVSgRqYDoV2AOecUsEZQWdF8NPTX4lurqFIq900jksq/o/RJmg2Nidek7+Kej BbGFfnSYsj0ZhbjUF8ad+mIPHRViS+nTQtA21y/Ab8uZ+Ykp7YVvKc/OoFh5/YwltdoT ZhtIru+tkZnR+bvjuI9xnZCjhRS40dituNXJ9RjrDm6NxicgzWwk+w7xIu2FYsFVC7ul d3yAugLn/TzPA1xEnj1PqmvhjO+ZwEJoUU6JVJu/2ddReAbFRkJuW12c7wioSd598zRb nwMCB5vaVOps86/6evgAfj/yYDwj7xjkXIY4qZmjaUhOzaFkWhmDnYxkIWItuaTrsZuO W4Zg== X-Forwarded-Encrypted: i=1; AJvYcCW94ASaI5Ew/Z1hGjjWS/x+opYKQpOGNwVvoaRWUODexRNI/0vXTjDIBKUy0djVg/2HFkVx7g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxpmf/QNl4cmRCGoMjac9dsYlIa0+9YMChyR6/AlM/67N//Vh2F 5T+AK4YYA0971Kavbv2Fl+KUOdz8WD6pTFbLlAcXr8gs9aON1YiN+tjmzw== X-Gm-Gg: ASbGncuYfARjAm2vufTt/pJQva0crp7GHCaoYQ3J8Hr+NY1AMSXwL45K5LlsAYy0z4M HM4Dfg93pNYOSGnOBrQpiRIgR0lbTRg6N/mw8n/0sz00FMLdX0lO4e49w/xWYtxbkPw+0HjN9qK oL6tfVAyCovLTEMQFGHsmwwvVxrIPhnhvTniII0kdxffh5Bx1+aJUjoNyVgIieYbY1KusUhOS/Z JlprpULfwIosdnleXpM1bZinqGzWaEX1ITayDuxPxzDwLy1L/02xBBGv7rQRfhH/EBn0EL1iGuS R1kuXeo7yX+O1+jXWJP6+99wJNIxAH9Y31Jdr3tXSd1JMV4hpdujiLlHJITcC+lQYg== X-Google-Smtp-Source: AGHT+IEUzTdMUcRwj8TGaaWicE8fObC5/1H/eD/Jbu3Q3HSPV3c3G0eqoH0t7hPss5/PrUuSXNMDWQ== X-Received: by 2002:a5d:598d:0:b0:385:e013:39ef with SMTP id ffacd0b85a97d-38a221e30aemr41580260f8f.6.1736107498767; Sun, 05 Jan 2025 12:04:58 -0800 (PST) Original-Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c832ec4sm45609955f8f.26.2025.01.05.12.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 12:04:58 -0800 (PST) In-Reply-To: <86h66d6pw1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 21:07:26 +0200") 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:298603 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >> Date: Sun, 05 Jan 2025 19:17:37 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > 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? >>=20 >> That args is a parameter >>=20 >> call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, >>=20 >> 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?=20=20 >>=20 >> 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. I'm bowing out again. It's not worth it.