From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: FACE_FROM_ID vs FACE_OPT_FROM_ID Date: Fri, 24 Jun 2016 23:34:56 +0200 Message-ID: <576DA780.4080801@cs.ucla.edu> References: <83d1n73c5z.fsf@gnu.org> <576C7D75.4070401@cs.ucla.edu> <8360sz2cpc.fsf@gnu.org> <576CFCFE.8050908@cs.ucla.edu> <83ziqa29gd.fsf@gnu.org> <576D16D3.2000801@cs.ucla.edu> <83twgi1z4m.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466804160 22385 80.91.229.3 (24 Jun 2016 21:36:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2016 21:36:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 24 23:35:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bGYlQ-00008I-2h for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2016 23:35:48 +0200 Original-Received: from localhost ([::1]:47399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGYlP-0000wr-Bv for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2016 17:35:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGYko-0000tV-Oj for emacs-devel@gnu.org; Fri, 24 Jun 2016 17:35:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGYkm-000811-My for emacs-devel@gnu.org; Fri, 24 Jun 2016 17:35:09 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGYkh-0007uK-No; Fri, 24 Jun 2016 17:35:03 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 251A21614D2; Fri, 24 Jun 2016 14:35:02 -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 UbslmBwWbV7L; Fri, 24 Jun 2016 14:35:01 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5FA851614EF; Fri, 24 Jun 2016 14:35:01 -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 KeG_vesaZrk5; Fri, 24 Jun 2016 14:35:01 -0700 (PDT) Original-Received: from [192.168.1.2] (host82-219-dynamic.32-79-r.retail.telecomitalia.it [79.32.219.82]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 80CAD1614D2; Fri, 24 Jun 2016 14:35:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <83twgi1z4m.fsf@gnu.org> 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:204741 Archived-At: On 06/24/2016 03:43 PM, Eli Zaretskii wrote: > When ENABLE_CHECKING is not defined, which is what happens by default > in Emacs builds, we attempt to "do the best we can without crashing", No, assertions should be always true; if an assertion fails Emacs should just abort, and should not try to patch around the bug. This is the longstanding intent of assertions, both in Emacs and in traditional computer science. If X is a side-effect-free expression, then after an eassert (X) there is no point to testing whether X is true, because X is already known to be true. The code 'eassert (X); if (!X) foo (X);' is redundant and somewhat silly, just as the code 'while (X) if (!X) foo (X);' is redundant and somewhat silly. I suppose Emacs could have a different kind of check, for an expression that must be true when debugging but that might not be true in production. We could call it 'check_when_debugging (X)', say. Its semantics would be that Emacs aborts when debugging is enabled and X is false; but that X might be either true or false in production code. However, I don't think check_when_debugging (X) would be helpful. Unlike eassert (X), it won't help the reader or simplify later code, because later code won't be able to assume that X is true. Worse, it would cause Emacs behavior in debugging mode to diverge further from production mode, and the production-only code paths would not be easily debuggable. The whole thing would be considerably more confusing than what Emacs does now. It could be that the font and image caches are special cases that have a lot of bugs, and that we therefore want some sort of belt-and-suspenders treatment for them that goes beyond ordinary assertions. I don't see offhand why that would be, though. Are we getting an unusual number of bugs in that area, and if so what sort of bugs are they?