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: Mon, 22 Jan 2024 14:37:04 +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="36243"; 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 Mon Jan 22 15:38:03 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 1rRvR4-0009Kf-Vx for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Jan 2024 15:38:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRvQl-0000CT-Aw; Mon, 22 Jan 2024 09:37:48 -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 1rRvQR-0008IM-45 for emacs-devel@gnu.org; Mon, 22 Jan 2024 09:37:23 -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 1rRvQO-0003rd-ON for emacs-devel@gnu.org; Mon, 22 Jan 2024 09:37:22 -0500 Original-Received: (qmail 7604 invoked by uid 3782); 22 Jan 2024 15:37:08 +0100 Original-Received: from acm.muc.de (pd953a8c4.dip0.t-ipconnect.de [217.83.168.196]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Jan 2024 15:37:08 +0100 Original-Received: (qmail 6100 invoked by uid 1000); 22 Jan 2024 14:37:04 -0000 Content-Disposition: inline In-Reply-To: <11f4f47c-2873-4268-9bfb-c844545f27a6@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:315218 Archived-At: Hello, Paul. On Sun, Jan 21, 2024 at 21:19:30 -0800, Paul Eggert wrote: > On 2024-01-21 02:59, Alan Mackenzie wrote: > > I don't think the first patch is correct. With it applied, the code > > no longer signals the error of a symbol with position being processed > > when symbols_with_pos_enabled is false. That's in the debug build, of > > course. > Oh, I think I see what you mean: although the patch is correct when > callers use XSYMBOL correctly, .... No, the patch is wrong. If things only had to work when callers call things correctly, we could scrap an awful lot more error checking code and speed Emacs up enormously. > .... if a caller has a bug that causes it to call XSYMBOL on a > symbol-with-position when symbols_with_pos_enabled is false, then > because of the patch this bug in the caller won't be diagnosed by an > eassert failure within XSYMBOL in a debug build. Yes. This is a bug. > I installed the attached to try to fix that. This patch doesn't affect > regular builds and so should preserve the minor performance advantage on > regular builds. Your latest patch doesn't fix it. 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. Please fix this. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).