ANSI assert

[Richard A. O'Keefe]

In article <1428 at proto.COM>, joe at proto.COM (Joe Huffman) writes:
> In the latest version of 'The C User Journal' P.J. Plauger wrote about the
> assert 'function' under ANSI C.  ...  It appears
> to me that [Plauger's code] is wrong (it would break nearly all of my code).

> My concern is when NDEBUG is defined.  I have many places in my code where I
> do something like the following:
>   assert(i++ < limit);
> either someone overlooked a potential problem or my coding
> style is going to have to be revised (as well as 10's of thousands of lines
> of code). 

Your code is *ALREADY* broken.  The ``de facto'' standard in UNIX has been
	#ifdef NDEBUG
	#define assert(ex) /**/
	#else
	...
	#endif
or something very like it for a long time.  For many people it has been
important that the test *not* be evaluated when NDEBUG is defined; if
the tests are cheap enough that you want them to be done anyway you
would be rather silly to do all that work and not take advantage of it!
A common case is
	assert(very_costly_checking_call());
where the _point_ of NDEBUG is to avoid the call when not debugging.

The argument of assert() has no business producing side effects.  Quite
apart from assert being a macro rather than a function, assert() is
supposed to be used the way you would use assertions, and assertions
are *pure* boolean formulas.  The "discourse convention" used by human
beings is that assertions are comments about the code, not an integral
part of it, so if you put side effects in your assert()s your _human_
readers are going to be very confused by it.
-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.