Re: FACE_FROM_ID vs FACE_OPT_FROM_ID

[Paul Eggert]

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.