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: Tue, 23 Jan 2024 11:42:43 +0000 Message-ID: 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=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6188"; 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 Tue Jan 23 12:43:48 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 1rSFC0-0001MD-1F for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jan 2024 12:43:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSFB6-0003jH-4C; Tue, 23 Jan 2024 06:42:52 -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 1rSFB3-0003hM-G4 for emacs-devel@gnu.org; Tue, 23 Jan 2024 06:42:49 -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 1rSFB1-0002C5-9N for emacs-devel@gnu.org; Tue, 23 Jan 2024 06:42:49 -0500 Original-Received: (qmail 25227 invoked by uid 3782); 23 Jan 2024 12:42:44 +0100 Original-Received: from acm.muc.de (p4fe15d8f.dip0.t-ipconnect.de [79.225.93.143]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 23 Jan 2024 12:42:43 +0100 Original-Received: (qmail 19492 invoked by uid 1000); 23 Jan 2024 11:42:43 -0000 Content-Disposition: inline In-Reply-To: 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:315248 Archived-At: Hello, Paul. On Mon, Jan 22, 2024 at 23:51:50 -0800, Paul Eggert wrote: > On 2024-01-22 06:37, Alan Mackenzie wrote: > > In a regular build, symbols with > > position are handled differently depending on the value of > > symbols_with_pos_enabled. Or at least they were and they must be. Thus > > in XBARE_SYMBOL, one MUST test s_w_p_e, regardless of whether the build > > is a regular one or a debugging one. > None of my recent patches changed XBARE_SYMBOL. If XBARE_SYMBOL should > test something it isn't currently testing, then that is a bug that has > been present for some time. > However, I don't see a bug there. XBARE_SYMBOL should be used only on > bare symbols, regardless of whether symbols_with_pos_enabled is set. > Perhaps you meant to write XSYMBOL instead of XBARE_SYMBOL? Yes I did. Apologies. > If so, I'm still not following, and more explanation would be helpful. > What call to XSYMBOL formerly would have an eassert failure when > debugging, but now won't have that failure? 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. This is what I'm asking you to fix. -- Alan Mackenzie (Nuremberg, Germany).