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 00:15:03 -0800 Organization: UCLA Computer Science Department 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; 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="26245"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Alan Mackenzie , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 23 09:16:01 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 1rSBwt-0006VZ-Nw for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jan 2024 09:16:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSBw7-00074n-QZ; Tue, 23 Jan 2024 03:15:11 -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 1rSBw6-00073f-DR for emacs-devel@gnu.org; Tue, 23 Jan 2024 03:15:10 -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 1rSBw3-0007ny-Jw; Tue, 23 Jan 2024 03:15:09 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 4CA543C011BD4; Tue, 23 Jan 2024 00:15:04 -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 J2upRq4zi6Qj; Tue, 23 Jan 2024 00:15:04 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 058A83C011BD7; Tue, 23 Jan 2024 00:15:04 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 058A83C011BD7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1705997704; bh=3W/sb02kSCxJPtqbo9gecJFppzf+gVmlXGuxVC9Moq0=; h=Message-ID:Date:MIME-Version:To:From; b=jMuVsQdf4P5i3Iim9g23f5lnHaQ5+sBLkLFgBu3qVYu34NebXudkyvrd4R/91EbmL Z+HrV1lAs2v5+W4mB7unwocOlxyNPMGBMyka3iGcEsroQheLmyrEsN4WUEWcptnLkF Ep5/QrSoG4dT/BsG5DwzgCUC5Sb5WgO56RlQkTK8ha4wNWKVdVAB9q42jywa5g/jlt QQ2zDPaSZSKKNxOO2mzpPWZq8Q+X//dwbszlACZqpVkL/CaWdDVP86u6IDmnuwzf3z sDynIaYXUpt9dfMDTv/j4SZmKvkXSfeffsFClAe/zt9mjjiMlZ9QI7DaNKG3JMMxQL EnVET6ueKWncQ== 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 whLsH1ZbwwWN; Tue, 23 Jan 2024 00:15:03 -0800 (PST) Original-Received: from [192.168.254.12] (unknown [47.148.192.211]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id D9FA93C011BD4; Tue, 23 Jan 2024 00:15:03 -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:315247 Archived-At: On 2024-01-22 05:20, Stefan Monnier wrote: > 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` Yes, when --enable-checking is used the tradeoff is: would we rather omit all runtime checking in make_lisp_symbol (the patch you proposed), or omit it only for builtin symbols (the patch I installed)? For builtin symbols like Qnil and Qt the runtime checking is not all that useful - if these symbols' data items are improperly aligned Emacs will crash early anyway. For non-builtin symbols the runtime checking is arguably useful, to catch (presumably rare) alignment bugs in the memory allocator. If you'd rather have the simpler solution that doesn't catch alignment bugs in non-builtin symbols, I could prepare a patch along those lines. Any such alignment bugs are pretty unlikely, after all. > (worse: the logic is actually not the same, so it's >> not obvious that it ends up returning the same thing). I used that logic to convince gcc to optimize builtin symbols like Qt and Qnil into integer constants at the machine level even when -O0 is used. But if nobody needs that sort of performance with -O0, we could go back to the old way of doing things. (It's obvious to *me* that the two formulations are equivalent but hey! only four people in the world understand lisp.h and nobody knows which four people they are....)