|
From: | Paul Eggert |
Subject: | Re: FACE_FROM_ID vs FACE_OPT_FROM_ID |
Date: | Fri, 24 Jun 2016 13:17:39 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |