From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Excessive use of `eassert` Date: Mon, 22 Jan 2024 08:20:13 -0500 Message-ID: References: <83jzo5x0q8.fsf@gnu.org> <83sf2tv029.fsf@gnu.org> <811d5f03-fad4-47e1-b3fd-2f45229a5ee1@cs.ucla.edu> <1bcc2fc4-da9f-488e-b416-ef4443a3da65@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29577"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alan Mackenzie , Eli Zaretskii , 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 14:21:22 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 1rRuEr-0007Rj-1d for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Jan 2024 14:21:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRuE8-0007XN-6R; Mon, 22 Jan 2024 08:20:37 -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 1rRuDu-0007W4-B1 for emacs-devel@gnu.org; Mon, 22 Jan 2024 08:20:24 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rRuDr-000592-RF; Mon, 22 Jan 2024 08:20:21 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C6E2B4413E5; Mon, 22 Jan 2024 08:20:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705929614; bh=OW1es01s+EQtvDo0eUJsrGzgWc+tCc/tcfqKuUPaUTk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DgVZuh73BoAOJDUVeqKbXeVBxjy137daVcdha+F5gAIN2I68sMv3GiAOSJ1uEM4sU QWzHA4dW17DOeUKem7M68tpTzacnBmM4eHTN3W8NMPh+XlgWnOtAR6aZPXWQomfkTC cDyBUxr3Yj2lfemUaI6BOIuk9vB7dWnlfuUeN4NgOSZyYNbw4QrjS1uUUMkl6iVDS/ bkP9ysMBOII0YxlfCBK1WxzrIVbadROBh1VzubEVtF6s4SM4oaI/6x6Gd4MqXJ9Ybq pwfL4LKmlMq1UBrgvEEZDEZACFiIAqz/eBrhOIHl1Ly5WahYxtEljyWh2Y1UGBHzTW rr8jFojhWvkOw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 949E04409E1; Mon, 22 Jan 2024 08:20:14 -0500 (EST) Original-Received: from pastel (104-222-114-253.cpe.teksavvy.com [104.222.114.253]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 69899120490; Mon, 22 Jan 2024 08:20:14 -0500 (EST) In-Reply-To: <1bcc2fc4-da9f-488e-b416-ef4443a3da65@cs.ucla.edu> (Paul Eggert's message of "Sun, 21 Jan 2024 20:12:09 -0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:315215 Archived-At: > Thanks, I reproduced that on Ubuntu 23.10 on x86-64 by configuring > with --enable-checking and compiling with gcc -O0. FWIW, I never compile with `-O0`, it's usually`-Og`. And on i386 I saw it with `-O2` as well :-( > +/* Equivalent to "make_lisp_symbol (&lispsym[INDEX])", > + and typically faster when compiling without optimization. */ > +#define lisp_h_builtin_lisp_symbol(index) \ > + TAG_PTR (Lisp_Symbol, (index) * sizeof *lispsym) [...] > +(builtin_lisp_symbol) (int index) > { > - return make_lisp_symbol (&lispsym[index]); > + return lisp_h_builtin_lisp_symbol (index); > } Hmm... Compared to the patch I proposed this has the downside that it duplicates the logic between `lisp_h_builtin_lisp_symbol` and `make_lisp_symbol` (worse: the logic is actually not the same, so it's not obvious that it ends up returning the same thing). Stefan