From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 74f54af: Use eassume (false) for branch that's never taken. Date: Tue, 23 Apr 2019 09:56:15 -0700 Organization: UCLA Computer Science Department Message-ID: References: <83ftqecrms.fsf@gnu.org> <83ef5ycnny.fsf@gnu.org> <9b3a1717-64de-795a-2acf-0698576caf02@cs.ucla.edu> <83zholbvnb.fsf@gnu.org> <25791a2b-260e-9cee-b454-5d9f53fa33e0@cs.ucla.edu> <83r29xb3co.fsf@gnu.org> <27636c2b-549d-4e78-a1e3-af78605ebd1e@cs.ucla.edu> <837ebl5jmd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="221868"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: phst@google.com, p.stephani2@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 23 18:56:46 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hIyir-000vaO-Gw for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 18:56:45 +0200 Original-Received: from localhost ([127.0.0.1]:56777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIyiq-0006oo-HG for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 12:56:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIyij-0006nw-UV for emacs-devel@gnu.org; Tue, 23 Apr 2019 12:56:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIyih-0002Lm-Mp for emacs-devel@gnu.org; Tue, 23 Apr 2019 12:56:37 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:53058) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hIyia-00027J-JV; Tue, 23 Apr 2019 12:56:30 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7DDE2161763; Tue, 23 Apr 2019 09:56:16 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d1IUEeortM7B; Tue, 23 Apr 2019 09:56:15 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9564E161775; Tue, 23 Apr 2019 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lbn3A6_e7Uzy; Tue, 23 Apr 2019 09:56:15 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 75806161599; Tue, 23 Apr 2019 09:56:15 -0700 (PDT) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <837ebl5jmd.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235830 Archived-At: On 4/22/19 11:19 PM, Eli Zaretskii wrote: > My mental model of using assertions in Emacs is slightly different. > In my model, we use eassert for things that "cannot happen", but can > be tolerated in some sense in a production build. "Tolerate" here > means that the result could be incorrect display or some strange error > message or a crash in some unrelated place. This is not a model I'm familiar with, and many (most?) executions of eassert don't behave that way. For example, when XCAR (via XCONS) uses eassert to check that its argument is tagged as a cons, any assertion failure means Emacs is in a seriously bad state. Quite possibly Emacs will crash immediately; but even if Emacs lucks out and doesn't crash immediately it's not something that should be tolerated. > If something that "cannot > happen" causes an immediate problem, i.e. the code simply cannot > continue, then we should call emacs_abort instead. Again, that's not what I would expect. Many (most?) executions of 'if (!X) emacs_abort ();' won't necessarily prevent an immediate problem. For example, string_bytes has such a test, even though string_bytes won't crash immediately if the test is omitted. In practice, I think the more accurate characterization is that we use eassert for runtime checks done in testing but not in production, and we use emacs_abort for runtime checks always done even in production. We're more likely to prefer emacs_abort to eassert if the runtime check is cheap or is rarely needed, or if the failure is more likely or has worse effects. Whether the failure would occur immediately after the check is not that relevant. > If non-production builds use -fsanitize=reachable, and if doing so > will cause an abort when the condition is violated, then yes, maybe we > should do that. -fsanitize=undefined implies -fsanitize=reachable, so if we encourage the use of -fsanitize=undefined then we should be on a good path here. > And it doesn't help > that with current build machinery one needs to manually specify all > the compiler switches, instead of using some simple configure switch > that automatically does that for us. Using one more switch increases > that burden slightly. We could have --enable-checking default to -fsanitize=undefined on platforms that support it.