TITLE: Guarding complex macros

PROBLEM: jamshid (Jamshid Afshar), 11 May 94

ASSERT, or any macro containing individual statements (like an if) or
a block, should be "guarded".  Otherwise we end up with the following
confusion:

	#define ASSERT(cond) \
	    if (cond)  \
	       AssertFailure( VersionId, __LINE__, MAK_STRING(cond) );

	int blah( int x, int y ) {
	   int z = 0;
	   if (x>y)
	      ASSERT(x<MAX);
	   else        // This `else' does not match the `if' you think it does
	      z = y;   // With current ASSERT definition, this assignment gets
	               // executed only when x>y and x<MAX  !!
	   return z;
	}

A common workaround for this problem is to surround function-like
macros with a do-while(0) statement.  This "macro guard" keeps users
of the macro from having to remember different langauge rules (eg,
don't use a semicolon, don't use it in an if statement, surround it
with braces, etc) when using your macro.

	#define ASSERT( cond )                                \
    	   do { \
	      if ( ! ( cond ) ) \
	         AssertFailure( VersionId, __LINE__, MAKE_STRING( cond ) ); \
	   } while (0)

[...]

Btw, I forgot to mention that `do while(0)' is optimized away by
either Cfront or the C compiler, even without turning optimizations
on.  The same assembly is created for either:

	do {   // code for ASSERT(x!=0)
	   if (!(x!=0))
	      fail("x!=0");
	} while (0);

or

	if (!(x!=0))   // code for ASSERT(x!=0)
	   fail("x!=0");