g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  Index 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: NDEBUG
From: Andrew Johnson <anj@aps.anl.gov>
To: Jeff Hill <johill@lanl.gov>
Cc: EPICS core-talk <core-talk@aps.anl.gov>
Date: Fri, 25 Apr 2008 09:41:25 -0500
Hi Jeff,

Jeff Hill wrote:

The question comes up from time to time about whether NDEBUG should be set
when it's an optimized build (that's not currently the case). There are two
issues.
The first one is whether assert tests should remain in optimized builds or
not. I can argue on both sides of that one, but maybe not today ;-)

I think the response to that when you brought it up last week was that we should keep our current assertion tests live in production builds.

The second one is what to do with similar types of consistency checking that
clearly have very negative performance impacts on the production system, but
nevertheless should be checked (maybe only in debug builds) during
regression testing. An example are features in the EPICS mutex that verifies
that the same thread that locks the mutex is also unlocking it (on certain
os this is already provided in the debug version of the runtime library I
suspect). There are more concerns about this type of bogosity when Guard
classes are in use because it's easier for a misguided developer to place a
Guard in other than automatic (stack) type of variable. A parallel situation
exists also with the Guard releasing class (maybe the os specific debug
version of the runtime library can't help us with this one). Furthermore,
with the guard releasing class it's easier to make dumb mistakes (I have to
admit that this comes from personal experience with misusing the guard
releasing class).

Based on the above two paragraphs I think I am starting to see that maybe we
have two reputable options.

1) Set NDEBUG in optimized builds and use it to remove the high overhead
stuff also.

Don't like, we see quite a few bug reports from assertions firing — just search tech-talk for 'assert' to see that.

2) Standardize throughout base on a new flag controlling the removal of high
overhead consistency checking code and set this flag by default in
production (optimized) builds.

If you're thinking about adding some expensive consistency checking that will significantly affect performance when enabled then I fully agree to having them disabled in production builds. However I don't particularly like the idea of having them enabled whenever the OPT flag is off, since it then becomes hard to separate out bugs that are caused by a compiler when optimization is turned on; I'd much prefer a separate switch which can be set on a per-subsystem or even per-compilation unit basis, separate from the compiler optimization switch.

- Andrew
--
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke

Replies:
Re: NDEBUG Ben Franksen

Navigate by Date:
Prev: Problems with bug in make 3.81 Ralph Lange
Next: Re: NDEBUG Ben Franksen
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: Problems with bug in make 3.81 Ralph Lange
Next: Re: NDEBUG Ben Franksen
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·