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: Sat, 04 Jan 2025 09:47:43 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.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="25114"; 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 Sat Jan 04 09:48:24 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 1tTzpX-0006Mb-B1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 09:48:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTzpF-0002vM-3T; Sat, 04 Jan 2025 03:48:05 -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 1tTzpD-0002vB-7B for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 03:48: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 1tTzpC-0003ET-UQ for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 03: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=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=4Yj+8I2z5A+PSLLRq8Z4MtH7FTc0sIX18Mc/h4EdC6w=; b=MRIQjfnTMjzGfHnTb3TNxRqJFEH+Ib7RmBF0f2+lQ9lUvxDaC7p00YfPX4TsK06NhKo9Dg0IWilutacnCBf5czQLXxQult6/5MU3cwRPXFOPSV9cqcGwzmM5j54Nt7NalNXP2YUTjkfd6PmODBXF7FngzRsQ7USRlRcUnz6xKvZsV71KnUYhFYkpF2Or1vXYc2LMqgoWT/uvbbjzDytHhwqXIS/ZwmQbcTXAFDfuDOYf1GDJjrPoQqyS4oRoaDGqqDQ6c7WPXRharXO6wYBj9D31PlryejrHw15lDdbCLdx+ajTgg7XBx30jhPBHMavzyrFS4yfRDksQr1D01lyTqg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTzpC-0003RB-4i for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 03:48: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: Sat, 04 Jan 2025 08:48: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.173598047513200 (code B ref 75322); Sat, 04 Jan 2025 08:48:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 08:47:55 +0000 Original-Received: from localhost ([127.0.0.1]:53324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTzp5-0003Qq-46 for submit@debbugs.gnu.org; Sat, 04 Jan 2025 03:47:55 -0500 Original-Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:60883) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tTzp2-0003QZ-1w for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 03:47:54 -0500 Original-Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4361f664af5so145860515e9.1 for <75322@debbugs.gnu.org>; Sat, 04 Jan 2025 00:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735980465; x=1736585265; 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=4Yj+8I2z5A+PSLLRq8Z4MtH7FTc0sIX18Mc/h4EdC6w=; b=V8rm3z6xP2Z4miVqlilQQFlkfDfHjO0l6HEooLpuBzkL/+vPl5i/VQpA3gzZ+J0l2M nGMRpaisWXJ9Zb4jZlnVkQPXc3TpXNORuOlMyW5ZeJrCTsQVnlPea06CIXjHokGBtGCP 2rUzGMwTgHQWVA6TvcBrBQ6yE5dpy84l1p+5Ah8NKSGqIOdYHWkA1wYi/szbsDjaZ5sB AT+VwxJK51ldEiS3CiJyg5dHNq9syhhexQdb3grXuX0Zr9XyxDMyZUof8c0avNoooL6d XOyV9JCd8/CAT7EAOZ9ASz8uiI3WE3wlsLc1eeJKzehioK4yYiS5yOYdKe+qp8cZbD6G DOkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735980465; x=1736585265; 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=4Yj+8I2z5A+PSLLRq8Z4MtH7FTc0sIX18Mc/h4EdC6w=; b=DgwelZ7+tohFBDdopCkDTySnjCNyxQHzhKmmSNCLEWAJ432OJOxUpBuA739yV6WZTc Z0tFRZuyd6+Mz4uPUezECYUTaa93wBN7ylHrpw/xOU4eUWeW7GdgTXXtu+UkVmGmnR97 jyngD65KkO3FwFtQWlbFC2CcklWBJIga/97K3QbERRJN1BW6xdxJNLi5V3bK24jTB241 1Q4JaFou+pvnYH0pQATOEnQbJ8pFpznc88pf4Xfx76kwTQ1bRmWK6NSLr/RMr/do99ju 3lr8j4yLEMYE6YnEOesr/5pXuOB0B7/OvM1xkZ7T/7r3fVvzOSVEnlQCEpifrxO/+cyd CxiA== X-Forwarded-Encrypted: i=1; AJvYcCUbQgiUGPYT3xIRWgPaDwjJfPfyNTX5k2OfKV+SfxkezZExRg8Hl0C+1i99Mn6jl3WU/2vGqg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzLcUXzRuLrXP1oC3Dce0CdA7KtHdQb2lw0/IVjgkD35PU+9kdo AtZAlakvgaBH0b28AFDYNrDwlVuUvHGtrA3b3XM2USI7qu3OhDYipgkE8A== X-Gm-Gg: ASbGncvOOrTMnvXW0xLKfePnsqQ6G62H3aw/U3TByaW74WsFRgpW8KIk0P8eXm+z/QE /7KzHdy9ZOEJ7o41AAdimzDYsgk3Bf2i6kOVAggoilUqlMCRFoFdwDbOc1s0P32ck4CWt8g8QoF Q6N5E0a57A2xVP/EIMv52tDPSU6pL6WQs+DQONhffeOcb0ohCLLyE1I5NGTXbo29Mq2ZkpT/bTu gJIK+2IS/omY3NwW2b/FGabFYV7a0ZwWp8oVNXOtfleh5iTy/ipV4Dd6ftEgcv15Z6Lzrq0JjBV z03avO76+M7HXvoveqlOC2+nLkNG8AgrEdc49JFNcOFrNv2WR1ehRh6KXmXbzRRM/g== X-Google-Smtp-Source: AGHT+IH5J4yqFxsGMjEQtM95sLQeMck+A15rhNVdzGUY1sEtaHFWIDpFkX448zHqGoVyYA/hTVsi9w== X-Received: by 2002:a05:6000:4617:b0:385:f07b:93da with SMTP id ffacd0b85a97d-38a223f9e53mr37708455f8f.47.1735980465399; Sat, 04 Jan 2025 00:47:45 -0800 (PST) Original-Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c829015sm42663780f8f.13.2025.01.04.00.47.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 00:47:44 -0800 (PST) In-Reply-To: <86ed1jf1tp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Jan 2025 09:57:54 +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:298343 Archived-At: Eli Zaretskii writes: >> Cc: 75322@debbugs.gnu.org >> From: Gerd M=C3=B6llmann >> Date: Sat, 04 Jan 2025 05:40:09 +0100 >>=20 >> And today I see you reverted that commit. Is there something wrong with >> it? I couldn't see something wrong, and for me VALUE(no root) > >> VALUE(exact) VALUE(ambig). > > That's my fault. I asked to post the patch and discuss it before > committing, as these are delicate issues where I prefer that we all > are on the same page before changing this code. Ah okay, that explains it, I missed that discussion, sorry. >> WRT Lisp_Object allocas, please tell if I should do that. > > Let's discuss this on a case by case basis. Not all uses of alloca > are the same or have the same requirements and restrictions. Okay. For the SDATA case, I find Pip's commit does the right thing. It uses xstrdup for the strings and makes sure these are freed later by registering them in one of the special specpdl entries that exist for that purpose (record_unwind_protect_ptr). Works with both GCs, is always safe, I don't see disadvantages, and we don't have to check if GC runs or not and compact strings (old) or moves string data around (igc). For the Lisp_Object cases, I strongly suspect that these cases are an oversight and were left over when SAFE_ALLOCA_LISP was introduced. The reason for introducing SAFE_ALLOCA_LISP is, IMO, what Pip said (old GC): to make sure that the Lisp_Objects are marked, via specpdl stack entries again, when the specpdl stack(s) are marked. Not doing that looks definitely wrong. Replacing the other ALLOCA macros that are currently used for holding Lisp_Objects with SAFE_ALLOCA_LISP would solve things for both GCs.