suppress_checking

suppress_checking

[Juanma Barranquero]

Is there any point to the variable suppress_checking, or is it leftover code?

It is defined (and initialized to 0 by default, but not otherwise
modified in any way) in alloc.c, and the only use is in lisp.h:

  /* Extra internal type checking?  */
  extern int suppress_checking;
  extern void die P_((const char *, const char *, int)) NO_RETURN;

  #ifdef ENABLE_CHECKING

  #define CHECK(check,msg) (((check) || suppress_checking		\
  			   ? (void) 0				\
  			   : die ((msg), __FILE__, __LINE__)),	\
  			  0)
  #else

  /* Produce same side effects and result, but don't complain.  */
  #define CHECK(check,msg) ((check),0)

  #endif

Now, I suppose it could perhaps be useful while debugging, but if
that's the intended use, it's undocumented and quite a bit obscure...

             Juanma

Re: suppress_checking

[Richard Stallman]

    Is there any point to the variable suppress_checking, or is it leftover code?

Since eassert uses CHECK, this offers the possibility to turn off
eassert checking at run time.  However, eassert is no-op'd by default
at compile time, because ENABLE_CHECKING is normally not defined.

I don't see that it is useful, but I also don't see a point
in deleting it.

suppress_checking is implemented in a funny way: the expression to be
tested is computed and then ignored.  That would make sense if we were
concerned about function calls and side effects in the expression to
be tested.  However, if there were any, ENABLE_CHECKING would not work.
So we may as well test suppress_checking first.

Re: suppress_checking

[Juanma Barranquero]

On 10/23/07, Richard Stallman <rms@gnu.org> wrote:

> Since eassert uses CHECK, this offers the possibility to turn off
> eassert checking at run time.

Yes, that's why I said that I understood it could be useful when
debugging. My question was more like "it was put there *for*
debugging, or left by accident?". Because if it is intended for
debugging, a comment in the code would've been nice :)

> suppress_checking is implemented in a funny way: the expression to be
> tested is computed and then ignored.  That would make sense if we were
> concerned about function calls and side effects in the expression to
> be tested.  However, if there were any, ENABLE_CHECKING would not work.
> So we may as well test suppress_checking first.

AFAICS, the !ENABLE_CHECKING version of CHECK does evaluate (check)
too, so the side effects are intended.

On the other hand, the !ENABLE_CHECKING version of CHECK is not used
anywhere. CHECK is only used in eassert (in lisp.h) and
NULL_INTERVAL_P (in intervals.h), and always when ENABLE_CHECKING is
defined.

             Juanma

Re: suppress_checking

[Richard Stallman]

    AFAICS, the !ENABLE_CHECKING version of CHECK does evaluate (check)
    too, so the side effects are intended.

You are right, as regards CHECK by itself.

However, eassert is what the code really uses, and that is a different
story.  When !ENABLE_CHECKING, eassert does not compute the condition
expression at all.

So we might as well make CHECK not compute the condition expression
either.  Which means that it might as well test suppress_checking
first.

Re: suppress_checking

[Juanma Barranquero]

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

Re: suppress_checking

[Ken Raeburn]

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

Re: suppress_checking

[Ken Raeburn]

I've just added some comments for the CHECK macro in its current  
form, based on what I wrote up in my last email.

Ken

Re: suppress_checking

[Juanma Barranquero]

On 10/29/07, Ken Raeburn <raeburn@raeburn.org> wrote:

> I've just added some comments for the CHECK macro in its current
> form, based on what I wrote up in my last email.

Thanks for the detailed explanation and the comment in lisp.h.

             Juanma

Re: suppress_checking

[Stefan Monnier]

> 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

I always run with -DENABLE_CHECKING and I do know of one significant
side-effect: it requires a bit more than 1.3MB of purespace (as opposed
1.17MB without it).


        Stefan

Re: suppress_checking

[Ken Raeburn]

On Oct 29, 2007, at 15:06, Stefan Monnier wrote:
> I always run with -DENABLE_CHECKING and I do know of one significant
> side-effect: it requires a bit more than 1.3MB of purespace (as  
> opposed
> 1.17MB without it).

Interesting.

If we care, it would be possible to go after certain side effects  
like this and rewrite the original code so that the XSTRING etc  
macros are always invoked with side-effect-free expressions.  I can  
think of at least three or four ways to tackle the problem, with  
varying degrees of difficulty.  The question is, do we care....

Ken

Re: suppress_checking

[Richard Stallman]

    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,

We're interested in GCC, not particularly in "decent optimizing
compilers".  Does GCC in fact optimize these cases?

Re: suppress_checking

[Ken Raeburn]

On Oct 30, 2007, at 1:24, Richard Stallman wrote:
>     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,
>
> We're interested in GCC, not particularly in "decent optimizing
> compilers".  Does GCC in fact optimize these cases?

Certainly GCC would be the main one I'd care about performance-wise,  
and as far as I'm concerned sets the standard for "decent optimizing  
compilers", but I've heard people do sometimes use other compilers. :-)

I haven't actually checked lately if GCC optimizes these cases, but  
given that the test is generally extracting some bits from the object  
value and comparing against a constant, or maybe doing that and then  
fetching a few bits from a computed address to compare against  
another constant, it'd be a real bug in GCC if it failed to optimize  
doing this twice in a row with the same input value and without  
intervening memory writes.  But it is possible, at least in theory,  
that some regression might cause some version of GCC to fail to  
combine the identical calculations, and that it might even escape  
notice until after a release went out.

If there are intervening memory writes or nontrivial function calls,  
and the test in question requires examining the pointed-to values  
(e.g., for misc or vector subtypes), and GCC's alias analysis (which  
is constantly being improved) can't prove they're disjoint locations,  
there would be extra reads from memory, and the associated  
comparisons, unused branches to calls to the "die" function, etc.

...  Okay, I just ran a quick test on my Mac (powerpc, Apple-flavored  
gcc 4.0.1).  The disassembly of a test function that included "if  
(STRINGP (s)) return SDATA (s);", where "s" was an argument to the  
function, showed the test was performed once, and the "die" call  
wasn't present at all.

Ken

Re: suppress_checking

[Richard Stallman]

    > We're interested in GCC, not particularly in "decent optimizing
    > compilers".  Does GCC in fact optimize these cases?

    Certainly GCC would be the main one I'd care about performance-wise,  
    and as far as I'm concerned sets the standard for "decent optimizing  
    compilers", but I've heard people do sometimes use other compilers. :-)

Our priorities do not servo on what people use.  Emacs is part of the
GNU system, so the GNU system is the platform that carries the most
weight for our decisions.  Thus, if a certain choice is bad for use
with GCC and good for use with every other compiler, we won't do it.
That's the way every GNU package should be developed.

    ...  Okay, I just ran a quick test on my Mac (powerpc, Apple-flavored  
    gcc 4.0.1).  The disassembly of a test function that included "if  
    (STRINGP (s)) return SDATA (s);", where "s" was an argument to the  
    function, showed the test was performed once, and the "die" call  
    wasn't present at all.

That is good.