Peter Jay Salzman wrote:
On Thu 18 Jan 07,  4:14 PM, Bill Kendrick <[EMAIL PROTECTED]> said:
So at work, a coworker noticed an issue with the following code:

  for (i = 0; i < n; i++)
    myFREE(foo[i]);

which went away when he wrapped it in braces:

  for (i = 0; i < n; i++)
  {
    myFREE(foo[i]);
  }

Figured maybe it was a weird compiler bug.  Being author of the myFREE()
code -- which happens to be a macro -- I realized immediately what I did
wrong.  (And continue to be annoyed with C syntax ;) )

See, myFREE() is actually a macro that looks like this:

  #define myFREE(x) if ((x) != NULL) FREE(x); x = NULL;

Two statements... hence the need for {} around the call to the macro.
(Or, more sensibly, including {}s around what the macro expands to.)

That was a neat catch. :)
I ran into something similar, but more complicated, last week.  An
expression that should've executed didn't.

I looked at the output of "cl.exe -E" (similar to gcc -E) which displays
what the compiler "sees" after the preprocessor does its thing.  From this
view, it was easy to see that what looked like:


   if ( some condition )
      die( some error message )
   else
      do_something();


was arriving at the compiler as:


   if ( some condition )
      if ( lots of stuff )
         print error message with lots of stuff.
      else
         do_something();

So the code needs to look like:

   if ( some condition ) {
      die( some error message )
   } else {
      do_something();
   }


Pete

This is why Lisp has those parentheses...   ;-P
And don't get me started about Lisp macros versus the C preprocessor.
_______________________________________________
vox-tech mailing list
[email protected]
http://lists.lugod.org/mailman/listinfo/vox-tech

Reply via email to