From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Excessive use of `eassert` Date: Wed, 24 Jan 2024 15:09:06 +0000 Message-ID: References: <83sf2tv029.fsf@gnu.org> <811d5f03-fad4-47e1-b3fd-2f45229a5ee1@cs.ucla.edu> <11f4f47c-2873-4268-9bfb-c844545f27a6@cs.ucla.edu> <3bd8a47a-f082-43f3-a46e-1e35d99b0f01@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39179"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 24 16:10:05 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 1rSetB-000A35-34 for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jan 2024 16:10:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSesO-0002UY-2K; Wed, 24 Jan 2024 10:09:16 -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 1rSesL-0002UD-A3 for emacs-devel@gnu.org; Wed, 24 Jan 2024 10:09:13 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rSesJ-0003G0-9o for emacs-devel@gnu.org; Wed, 24 Jan 2024 10:09:13 -0500 Original-Received: (qmail 12669 invoked by uid 3782); 24 Jan 2024 16:09:07 +0100 Original-Received: from acm.muc.de (p4fe15939.dip0.t-ipconnect.de [79.225.89.57]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 24 Jan 2024 16:09:06 +0100 Original-Received: (qmail 7709 invoked by uid 1000); 24 Jan 2024 15:09:06 -0000 Content-Disposition: inline In-Reply-To: <3bd8a47a-f082-43f3-a46e-1e35d99b0f01@cs.ucla.edu> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:315315 Archived-At: Hello, Paul. On Tue, Jan 23, 2024 at 17:04:44 -0800, Paul Eggert wrote: > 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. That's humpty-dumpty logic. Just because s-w-p-e is false is no guarantee that XSYMBOL won't get a SWP as argument. > 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. No, I'm saying that an invalid bit pattern in XSYMBOL's logic should not be treated as though it were valid. No other invalid bit pattern allows Emacs to continue blithely unaware. And as for "can slow down execution", your measurement of 0.4%, if it's not just background noise, is microscopic. That would be less than a second in a 4 minute bootstrap build. > 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. In normal builds, an invalid argument leads to a crash. After your patches, it only sometimes leads to a crash. This is a loss of functionality. Why did you not discuss this change in functionality on the list _before_ making it? > 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. The behaviour is not formally "undefined" and never has been. It is not formally anything (which is why we're arguing about it). You've changed the definition to "behaves as though symbols_with_pos_enabled were true". This breaks the consistency of the symbols with position mechanism. All for a barely measurable speed up. Or should we just accept SWP everywhere, and abolish symbols_with_pos_enabled? That would at least preserve consistency, though I don't think it would be a good thing to do. [ .... ] > 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. That feels like a bug. [ .... ] > For Emacs to reliably crash right away in situations like these, it > needs to be built with --enable-debugging. That is impractical for most developers due to the vast slowdown (not just 0.4%) it causes. Again, please restore the functionality you've ripped out. -- Alan Mackenzie (Nuremberg, Germany).