[vox-tech] Nifty macro expansion bug
Peter Jay Salzman
p at dirac.org
Fri Jan 19 12:14:44 PST 2007
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
--
How VBA rounds a number depends on the number's internal representation.
You cannot always predict how it will round when the rounding digit is 5.
If you want a rounding function that rounds according to predictable rules,
you should write your own.
-- MSDN, on Microsoft VBA's "stochastic" rounding function
Peter Jay Salzman, email: p at dirac.org web: http://www.dirac.org/p
PGP Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
More information about the vox-tech
mailing list