[vox-tech] Nifty macro expansion bug

[Harold Lee]

Peter Jay Salzman wrote:
> On Thu 18 Jan 07,  4:14 PM, Bill Kendrick <nbs at sonic.net> 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.