On Oct 27, 08 10:38:16 -0700, Conn Clark wrote:
Here is a revised version of my patch. It now includes changing a few calls to _RHDRegRead and _RHDRegWrite to using my macros. It also changes the way I did one macro to make it a little more bulletproof.
Interesting. Still a few *important* comments about general macro
programming - some of which result in changing the code for sure:
- In general, macros should be caps only, because there is a subtle
difference between function calls and macros: Side effects.
A macro can evaluate one or more of its arguments none or multiple
times.
E.g. The macro
#define TEST(x) ((x)+(x))
TEST(i++); -> (i++)+(i++);
will increment i twice.
Another example:
#define TEST(x,y) (x ? y : 0)
TEST (i, f()); -> (i ? f() : 0);
will call f() only if i isn't 0 - which isn't obvious from the
invocation.
That said, we don't want to rename the call ATM. But you have to
verify that all uses of the macro won't have issues with these side
effects.
- Always(!) put arguments in parens:
e.g. #define TEST(x) ((x)+(x))
There might be syntactic errors or - worse - strange compilations if
you do not adhere to that.
#define TEST(x,y) (x * y)
TEST(1+2,3) -> 1+2 * 3
results 7, not 9 as expected.
- Always(!) put either the whole macro in parens (if you expect a return
value), or put it in do { ... } while(0) (without trailing ;):
e.g. #define TEST(x) ((x)+(x))
e.g. #define TEST(x) do { assert (x); globalvar = (x); } while (0)
If you don't, you get weird effects:
#define TEST(x) (x)+(x)
2*TEST(3) -> 2*(3)+(3)
returns 9, not 12 as expected.
#define TEST(x) assert(x); globalvar = (x)
if (bla) if (bla)
TEST(i); -> assert(i);
globalvar = (i);
In this case globalvar is ALWAYS set to i - which wasn't intended, and
is a *very* hard error to spot.
CU
Matthias
--
Matthias Hopf