From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Mon, 06 Jan 2025 10:08:49 -0500 Message-ID: <140EF998-8D55-4FB4-A8D1-C4F27152D4C1@dancol.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> <225431A0-98C1-4F95-B290-AB86F5379030@dancol.org> <87sepwvo04.fsf@dancol.org> <86v7us5b0o.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="15127"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: gerd.moellmann@gmail.com, 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 Mon Jan 06 16:09:40 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 1tUojb-0003kK-42 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 16:09:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUoj6-0000oE-69; Mon, 06 Jan 2025 10:09:08 -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 1tUoj1-0000n0-DA for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:09:04 -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 1tUoj0-0002oR-Us for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:09: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=bsPWXbLzSAbCmAW/UBLqjyJWYQ9ThESg4ADsIdOkTsE=; b=Exrcd7urEgF7Z2SK6iKbaQw3VyVaczJlAdmZsMeOQl7VaaKc3nBW982GEugyFCz+VmWYz1q3fxUPNqwT+LTsseB+iBJeY7hL9KORNxeqOcsoQ4+3KnOikWkZ92y9kNTfMXaAYejbg/Cdz+lPATFbNVJ8DahQOZU5GnoqehY26TPklURbJK7kMjlRw2mbuCVqnRUgtuPjdFySjXJznkT+GJvPMd7Xjt+2agCx+2VEG60j+kJqxwQckGmKCbP3gbwoqqRKNt986bM6dX1tbSCjTqnmqLItjeJ+P+wTEHeVvgOHhVBsJbkbxpC2VgnLGmtD3MpgWyMWeIpTmj3nOwSzmg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUoj0-0001Xm-P1 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2025 15:09: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.17361761375914 (code B ref 75322); Mon, 06 Jan 2025 15:09:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:08:57 +0000 Original-Received: from localhost ([127.0.0.1]:39644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUoiv-0001XK-1z for submit@debbugs.gnu.org; Mon, 06 Jan 2025 10:08:57 -0500 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:37570) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUoit-0001X9-02 for 75322@debbugs.gnu.org; Mon, 06 Jan 2025 10:08:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bsPWXbLzSAbCmAW/UBLqjyJWYQ9ThESg4ADsIdOkTsE=; b=HROWyIsNlAq2oHovwWPpK7+Meh lgDWwMNhuKL0cYa/Rhny2841ku25Y+i5iA4v0F+QlzZQIwDMPCjp3xxxOOE4a5Y+w4LjhLO7EjUCu dJOYIOpx+rRCpvcDBBdI23oKMg3FmTjlsz1gvKnAg6hWzKbzYs6jLw/HETR1+jZ3LbbZcAQkxTpLb 8wGzOQT978h/QFXccOO9V8k4zLUOrE6fTCFbrvEKZfXBU/UuYMSVESuQEbMdu3RhZXK0lgw01xGhK LiVXU7khCJHxsLf0TVIxUqmJjeyT5csfXHH4Ln+5lQV3WbNdf7sf2eSCSqfmkyZ6brdZhri2pDaMt TFxoHwJw==; Original-Received: from 2603-9001-4203-1ab2-fab1-0408-e627-6f43.inf6.spectrum.com ([2603:9001:4203:1ab2:fab1:408:e627:6f43]:49740 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tUoiq-0002bU-0f; Mon, 06 Jan 2025 10:08:53 -0500 In-Reply-To: <86v7us5b0o.fsf@gnu.org> 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:298672 Archived-At: On January 6, 2025 8:26:15 AM EST, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: gerd=2Emoellmann@gmail=2Ecom, eliz@gnu=2Eorg, pipcet@protonmail= =2Ecom >> Date: Sun, 05 Jan 2025 18:28:59 -0500 >>=20 >> Daniel Colascione writes: >>=20 >> Here's a demonstration of the problem=2E Run =2E/emacs -batch -Q --eva= l >> '(acos 0)'=2E If you leave demo_crash to true, Emacs will abort quickl= y >> after we detect a use-after-free=2E If you set demo_crash to false, Em= acs >> will run the loop all day=2E > >It is a well-known fact that inserting Fgarbage_collect in various >random places can cause bugs=2E=20 It's not a "random place"=2E It's demonstrating an unsafe pattern=2E > But expecting every Emacs C-level >hacker to write code that will endure such testing is impractical=2E =20 If someone can't write safe Emacs C code, he shouldn't be writing Emacs C = code at all=2E It is reasonable to expect people to follow the rules=2E Most new features should be in Lisp and changes to C code should be in ser= vice of making it possible to put more logic in Lisp=2E > We >routinely let much more easily-spotted blunders slip though=2E The >sheer number of subtleties and factoids you need to keep in mind when >writing safe code in Emacs is already inhumanly large=2E Yes=2E It's hard enough to write C code as it is=2E That's why people need= to write C code with clear and simple bright-line rules on memory safety= =2E For example, instead of thinking about whether this or that function sc= ope Lisp_Object is safe, just ban function scope Lisp_Object static variabl= es generally=2E Much lower cognitive burden this way=2E >We only get away because there are many places where GC cannot happen=2E We also get away with a lot because the old GC is non-moving=2E The things= we get away with are fragile whether or not the old GC being forgiving mak= es them technically safe=2E >Admittedly, with the proliferation of calls into Lisp, there's less >and less of these places each year=2E Yes, which is why it's best to make code GC safe in general=2E Just like w= e don't have to sprinkle the register keyword around anymore, we don't have= to try to get clever and avoid having to gcpro this or that thing=2E Prote= ct all the things=2E Simple and robust=2E