From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: xassert in dispextern.h Date: Tue, 01 Mar 2005 22:51:03 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109714838 32379 80.91.229.2 (1 Mar 2005 22:07:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Mar 2005 22:07:18 +0000 (UTC) Cc: emacs-devel@gnu.org, Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 01 23:07:17 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6FVB-0005Oi-2z for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 23:06:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6Fno-0000f3-HN for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 17:25:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6FjO-0006sJ-Rb for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6FjJ-0006qW-If for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6FjH-0006ef-Lu for emacs-devel@gnu.org; Tue, 01 Mar 2005 17:20:35 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6FGj-0006qL-CC for emacs-devel@gnu.org; Tue, 01 Mar 2005 16:51:05 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D6FGi-0001nc-RJ; Tue, 01 Mar 2005 16:51:05 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 01 Mar 2005 22:32:25 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34009 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34009 storm@cua.dk (Kim F. Storm) writes: > David Kastrup 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