From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Excessive use of `eassert` Date: Tue, 23 Jan 2024 17:04:44 -0800 Organization: UCLA Computer Science Department Message-ID: <3bd8a47a-f082-43f3-a46e-1e35d99b0f01@cs.ucla.edu> References: <83jzo5x0q8.fsf@gnu.org> <83sf2tv029.fsf@gnu.org> <811d5f03-fad4-47e1-b3fd-2f45229a5ee1@cs.ucla.edu> <11f4f47c-2873-4268-9bfb-c844545f27a6@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 24 02:05:34 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rSRht-0001hp-SA for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jan 2024 02:05:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSRhF-0003MN-8D; Tue, 23 Jan 2024 20:04:53 -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 1rSRhD-0003M6-Pj for emacs-devel@gnu.org; Tue, 23 Jan 2024 20:04:51 -0500 Original-Received: from mail.cs.ucla.edu ([131.179.128.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rSRhB-0008L5-Qo; Tue, 23 Jan 2024 20:04:51 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7C88D3C005163; Tue, 23 Jan 2024 17:04:45 -0800 (PST) Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id qxCJ0Y1oZWpU; Tue, 23 Jan 2024 17:04:45 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 1C5AB3C00516D; Tue, 23 Jan 2024 17:04:45 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 1C5AB3C00516D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1706058285; bh=ifP1JUfbVPVzTJTrJZdvLUf4+3b3zAFebiWwPR1xKxI=; h=Message-ID:Date:MIME-Version:To:From; b=Zt7KatNxbK7T6TA+mD0cmqQu/B5fZUOanvu+HzeWrOWA65K2qnTdJ8NH09EOeeRxR pfQ6LgAoujtmnZ33DSHEpykNb3M0rLs8VZFCdSiXMzKX2xztt0bE0iqg+TKiJvH0Nt NYCQpjYGf8oTTbjPGh4vzn5fY3KdU63biPn5TXGIhW6C/XjK8vr2qrWazEtaMbhF+3 LSv+sBnoASY3KZjO2fATibrmiRi++cUGkqmqvBSXr8Qf/c4tT8djH/lYlIAuXU4dix 4JFE4d7PzxStcmmGvLZnTfDrGj5reMFn2Yw3CD9cf/jPfehqOSun08pgppNrBa3qxc 2pI/lnnCHeexw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id If93djG7x1uf; Tue, 23 Jan 2024 17:04:45 -0800 (PST) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 00DDF3C005163; Tue, 23 Jan 2024 17:04:44 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=131.179.128.66; envelope-from=eggert@cs.ucla.edu; helo=mail.cs.ucla.edu X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315277 Archived-At: On 1/23/24 03:42, Alan Mackenzie wrote: > It's not about the debug build, but a normal build, where easserts don't > play a role. > > The scenario is when symbols_with_pos_enabled is false, and XSYMBOL is > invalidly given a symbol with position as argument. Before your > patches, this would lead to an exception. After your patches, this no > longer happens. I don't see a problem there. XSYMBOL can be called only on symbols, regardless of whether symbols-with-pos-enabled is true. When symbols-with-pos-enabled is false, XSYMBOL's argument therefore cannot be a symbol with position as these are symbols only when symbol-with-pos-enabled is true. It sounds like you're thinking that, even in normal builds (i.e., without --enable-debugging), XSYMBOL's implementation should have some sort of debugging code that is not needed for correct behavior and that can slow down execution. I don't see why that needs to happen. In normal builds, XSYMBOL does not check that its argument is a symbol, and it has undefined behavior if buggy C code gives it a non-symbol. As I understand it, a symbol with position SP is not a symbol if symbols-with-pos-enabled is false. This means it's OK if XSYMBOL (SP) has undefined behavior when symbols-with-pos-enabled is false in a normal build. Here's an example to try to make my meaning clearer. Suppose we define a buggy Lisp function in C as follows: DEFUN ("buggy-symbol-name", Fbuggy_symbol_name, Sbuggy_symbol_name, 1, 1, 0, doc: /* Return SYMBOL's name, a string. */) (Lisp_Object symbol) { return XSYMBOL (symbol)->u.s.name; } This C function has a bug: it doesn't check that its argument is a symbol before calling XSYMBOL. And because of the bug, this: (buggy-symbol-name (position-symbol nil 1)) has undefined behavior when Emacs is built without --enable-debugging. In the current implementation this undefined behavior causes buggy-symbol-name to return "nil", whereas it would be nicer in some sense if Emacs crashed and dumped core due to the bug in the C code. However, symbols with positions aren't necessarily being treated differently from other Lisp objects here. For example, this: (buggy-symbol-name "abc") also has undefined behavior, and on my platform this latter expression returns nil, also without dumping core. Although it would also be nicer in some sense if Emacs crashed and dumped core due to the bug in the C code, Emacs doesn't do that, for valid performance reasons. For Emacs to reliably crash right away in situations like these, it needs to be built with --enable-debugging.