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 13:17:39 +0200 Message-ID: <576D16D3.2000801@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> 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 1466767138 12499 80.91.229.3 (24 Jun 2016 11:18:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2016 11:18:58 +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 13:18:49 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 1bGP8K-0000dQ-BG for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2016 13:18:48 +0200 Original-Received: from localhost ([::1]:42668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGP8E-00006u-Aa for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2016 07:18:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGP7W-0008PB-6t for emacs-devel@gnu.org; Fri, 24 Jun 2016 07:18:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGP7U-00084w-8X for emacs-devel@gnu.org; Fri, 24 Jun 2016 07:17:57 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGP7M-00081c-D6; Fri, 24 Jun 2016 07:17:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 26DF41614D2; Fri, 24 Jun 2016 04:17:47 -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 XJ80l6YQ4_lO; Fri, 24 Jun 2016 04:17:46 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5FFF51614EE; Fri, 24 Jun 2016 04:17:46 -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 bUanxbdPdVuT; Fri, 24 Jun 2016 04:17:46 -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 516141614D2; Fri, 24 Jun 2016 04:17:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <83ziqa29gd.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:204724 Archived-At: On 06/24/2016 12:00 PM, Eli Zaretskii wrote: >> my reading of this: >> >> #ifndef ENABLE_CHECKING >> # define eassert(cond) ((void) (false && (cond))) /* Check COND compiles. */ >> >> is that when ENABLE_CHECKING is not defined, eassert does nothing >> useful. Yes, of course. eassert (X) should appear only in places where X must be true, i.e., where Emacs is seriously broken if X is false. That's the standard meaning for assertions. Another way to put it is that in general the behavior of eassert (X) is undefined if X is false.When (defined ENABLE_CHECKING && !suppress_checking), this undefined behavior happens to be a diagnostic and core dump. Otherwise the undefined behavior is whatever the underlying system does afterwards; when (!defined ENABLE_CHECKING) this yields better performance overall in the usual and expected case where Emacs is working properly. It is not necessary to put eassert (X) every place where an expression X must be true. It's helpful only when we reasonably suspect there might be a bug in Emacs, and where platforms typically will not immediately fail for other reasons when X is false. So, before a pointer dereference *P it's not necessary to do eassert (P != NULL) since typical platforms immediately dump core when dereferencing a null pointer anyway. Conversely, before a subscript operation A[I] it can be helpful to eassert (0 <= I && I < N), since typical platforms lack reliable subscript checking.