Re: xassert in dispextern.h

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>
>> Feel free to volunteer any differing information if you have it
>> available.  If you know of any problem in the last 4 weeks that has
>> been discovered and fixed due to the changed default, I'd be glad
>> to hear of it.
>
> It has revealed one bug in connection with iso-accents-mode, which
> also gave a hint for solving a crash in double-mode.

Ok.  And this detection would not have been possible if the _default_
setting of xassert had been changed so that its effect became visible
"in the wild"?  I am trying to weigh the relative advantages with
regard to bug reports when we have a "not for serious use" Emacs setup
as the default as against one that can _optionally_ be compiled for
debugging purposes and that might get wide-spread testing due to it
being usable.

> It has also identified a few other rough edges in redisplay code,
> but I still have to see any significant error being caugt by an
> xassert.

Well, I am still of the opinion that most of the rough edge cases can
be better tracked when Emacs does not quit working.

I think that the abort action of an assertion is only sensible when
the program can't be reasonably expected to continue.  And even then
there are some cases where the assertion is not necessary: like
checking a pointer for non-NULL before accessing stuff with it.  An
abort is not more comforting than SIGSEGV.

Assertions are best used for cases where the data is inconsistent and
a bombout at a different part of the program might result from it.
Then it is better to have the bombout where the problem occurs.

It has turned out for me to be a bit of a nuisance that gcc knows that
abort is "noreturn": it does not bother to keep the stack and
instruction path in any useful state, so using gdb's "return" function
from "abort" will get you into trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum