On Wed, 5 Jul 2006, Randy.Dunlap wrote:
>
> OK, I'll bite. What part of Linus's macro doesn't work.
Heh. This is "C language 101".
The reason we always write
#define empty_statement do { } while (0)
instead of
#define empty_statement /* empty */
is not that
if (x)
empty_statement;
wouldn't work like Arjan claimed, but because otherwise the empty
statement won't parse perfectly as a real C statement.
In particular, you tend to get much better error messages if you have
syntax errors _around_ the empty statement if it's done as that
"do { } while (0)" thing. You also avoid compiler warnings about
empty statements or statements without effects, that you'd get if you were
to use
#define empty_statement /* empty */
or
#define empty_statement 0
for example (a expression statement is a perfectly valid statement, as is
an empty one, but many compilers will warn on them).
It's also simply good practice - if you _always_ do the "do { } while (0)"
thing, you'll never get bitten by having a macro that has several
statements inside of it, and you'll also never get bitten by a macro that
is _meant_ to be used as a statement being used as part of an expression
instead.
It basically boils down to the fact that the "do { } while (0)" format is
always syntactically correct, /regardless/ of what is inside of the
braces, and should always give you meaningful error messages regardless of
what is _around_ the macro usage.
For example:
if (a)
empty_statement
b;
will give the _correct_ syntax error message ("expected ';'"), instead of
silently turning into
if (a)
b;
or other nonsense.
But in the end, the real aim is to just teach your fingers to _always_ put
the do/while(0) there, so that you never EVER write something like
#define MACRO one; two;
which really breaks down.
This is, btw, the same reason a lot of people (including me, most of the
time) will write
#define VALUE (12)
instead of writing the simpler
#define VALUE 12
just because it's good practice to _always_ have the parentheses around
a macro that ends up being used as an expression.
So we always also write
#define ADD(a,b) ((a)+(b))
because otherwise you eventually _will_ get bitten (we've had that
particular bug bite us in the *ss lots of times, even though people should
know better)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
