From: Ken Raeburn <raeburn@raeburn.org>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: suppress_checking
Date: Mon, 29 Oct 2007 13:51:47 -0400 [thread overview]
Message-ID: <E9978778-8C5B-4B41-8340-B55CE66B8891@raeburn.org> (raw)
In-Reply-To: <f7ccd24b0710240156p7c09c718l5c5229e7b154a9ba@mail.gmail.com>
On Oct 24, 2007, at 04:56, Juanma Barranquero wrote:
> On 10/24/07, Richard Stallman <rms@gnu.org> 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
next prev parent reply other threads:[~2007-10-29 17:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-22 15:59 suppress_checking Juanma Barranquero
2007-10-23 10:38 ` suppress_checking Richard Stallman
2007-10-23 10:59 ` suppress_checking Juanma Barranquero
2007-10-24 2:49 ` suppress_checking Richard Stallman
2007-10-24 8:56 ` suppress_checking Juanma Barranquero
2007-10-29 17:51 ` Ken Raeburn [this message]
2007-10-29 18:16 ` suppress_checking Ken Raeburn
2007-10-29 22:49 ` suppress_checking Juanma Barranquero
2007-10-29 19:06 ` suppress_checking Stefan Monnier
2007-10-29 20:47 ` suppress_checking Ken Raeburn
2007-10-30 5:24 ` suppress_checking Richard Stallman
2007-11-01 3:25 ` suppress_checking Ken Raeburn
2007-11-01 19:04 ` suppress_checking Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E9978778-8C5B-4B41-8340-B55CE66B8891@raeburn.org \
--to=raeburn@raeburn.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.