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