Re: suppress_checking

[Ken Raeburn]

On Oct 24, 2007, at 04:56, Juanma Barranquero wrote:
> On 10/24/07, Richard Stallman <address@hidden> 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