From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: suppress_checking Date: Mon, 29 Oct 2007 13:51:47 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1193680457 26762 80.91.229.12 (29 Oct 2007 17:54:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2007 17:54:17 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 29 18:54:18 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ImYoa-0001KD-TD for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2007 18:54:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImYoR-0007vb-LT for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2007 13:54:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ImYmg-0007JZ-1C for emacs-devel@gnu.org; Mon, 29 Oct 2007 13:52:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ImYme-0007IR-EN for emacs-devel@gnu.org; Mon, 29 Oct 2007 13:52:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImYmd-0007II-VN for emacs-devel@gnu.org; Mon, 29 Oct 2007 13:52:16 -0400 Original-Received: from alnrmhc11.comcast.net ([206.18.177.51]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ImYmZ-0003qb-BB; Mon, 29 Oct 2007 13:52:11 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (alnrmhc11) with ESMTP id <20071029175149b11002q90re>; Mon, 29 Oct 2007 17:51:50 +0000 Original-Received: from [69.25.196.100] (fwoosh.raeburn.org [69.25.196.100]) by raeburn.org (8.14.1/8.12.11) with ESMTP id l9THpmj3012823; Mon, 29 Oct 2007 13:51:49 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.752.2) X-detected-kernel: by monty-python.gnu.org: NetCache Data OnTap 5.x 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 Xref: news.gmane.org gmane.emacs.devel:82081 Archived-At: On Oct 24, 2007, at 04:56, Juanma Barranquero wrote: > On 10/24/07, Richard Stallman wrote: >> So we might as well make CHECK not compute the condition expression >> either. Which means that it might as well test suppress_checking >> first. > > It would be useful to know what was the intention with > suppress_checking, and how is used (if someone does use it indeed). > Currently there's a difference between > > #undef ENABLE_CHECKING > > and > > #define ENABLE_CHECKING 1 > suppress_checking = 1; > > because in the latter case, the check tests are still executed, though > its return value is discarded. Perhaps that difference was intended. > > Juanma My fault... as I recall, the idea was that the checking could be switched on or off at run time, maybe at a breakpoint, or by tweaking the executable with gdb, without requiring recompilation. Doing the test of suppress_checking after evaluating the condition meant that aside from possibly killing the process, the side effects would be the same either way. Currently CHECK is only used if ENABLE_CHECKING is defined, but that wasn't always the case. When the code was checked in, NULL_INTERVAL_P and eassert both unconditionally used CHECK; since then, both have been changed so that the possible side effects of enabling the checking code are different from running without it. In the eassert case, it looks like Gerd made that change a couple months after I checked the code in. Since CHECK itself just evaluates the test and does nothing with it if ENABLE_CHECKING is not defined, assuming you have a decent optimizing compiler, the main benefit in conditionalizing the other macros is if you think there may be side effects in the arguments, and you care more about the performance than keeping similarity of behavior when the debugging code is enabled. Given that XSTRING, etc., all call eassert to verify the type before extracting the pointer (or other) value, there's a good chance that there are side effects in some argument somewhere, so I guess a related question is whether that's okay, or we want the X* macro arguments to be side- effect-free to improve debugging. I'll also note that the HAVE_SHM version of XPNTR (which we might actually not be using any more?) evaluates its argument more than once in non-ENABLE_CHECKING mode. The changes I was experimenting with at the time were some significant low-level changes, and I was trying to add the type checking to XSTRING and friends, but evaluate separately whether multiple evaluations of arguments were the sources of problems I was seeing (versus bugs in the low-level changes I was trying to implement). So getting the double evaluations, independently of doing the type checking, was useful at the time. (As for ENABLE_CHECKING not being defined, I think I offered once to create an --enable- option for it, as I think the GCC folks have done since, but there wasn't much interest at the time. Still, it's easy enough to tweak sources or set flags through configure.) Ken