The do ... while
and if ... else
are there to make it so that a
semicolon after your macro always means the same thing. Let's say you
had something like your second macro.
#define BAR(X) f(x); g(x)
Now if you were to use BAR(X);
in an if ... else
statement, where the bodies of the if statement were not wrapped in curly brackets, you'd get a bad surprise.
if (corge)
BAR(corge);
else
gralt();
The above code would expand into
if (corge)
f(corge); g(corge);
else
gralt();
which is syntactically incorrect, as the else is no longer associated with the if. It doesn't help to wrap things in curly braces within the macro, because a semicolon after the braces is syntactically incorrect.
if (corge)
{f(corge); g(corge);};
else
gralt();
There are two ways of fixing the problem. The first is to use a comma to sequence statements within the macro without robbing it of its ability to act like an expression.
#define BAR(X) f(X), g(X)
The above version of bar BAR
expands the above code into what follows, which is syntactically correct.
if (corge)
f(corge), g(corge);
else
gralt();
This doesn't work if instead of f(X)
you have a more complicated body of code that needs to go in its own block, say for example to declare local variables. In the most general case the solution is to use something like do ... while
to cause the macro to be a single statement that takes a semicolon without confusion.
#define BAR(X) do { \
int i = f(X); \
if (i > 4) g(i); \
} while (0)
You don't have to use do ... while
, you could cook up something with if ... else
as well, although when if ... else
expands inside of an if ... else
it leads to a "dangling else", which could make an existing dangling else problem even harder to find, as in the following code.
if (corge)
if (1) { f(corge); g(corge); } else;
else
gralt();
The point is to use up the semicolon in contexts where a dangling semicolon is erroneous. Of course, it could (and probably should) be argued at this point that it would be better to declare BAR
as an actual function, not a macro.
In summary, the do ... while
is there to work around the shortcomings of the C preprocessor. When those C style guides tell you to lay off the C preprocessor, this is the kind of thing they're worried about.
The do while loop executes the content of the loop once before checking the condition of the while.
Whereas a while loop will check the condition first before executing the content.
In this case you are waiting for user input with scanf(), which will never execute in the while loop as wdlen is not initialized and may just contain a garbage value which may be greater than 2.
Best Answer
Just a guess as to why they might suggest using
over
Even though there's no behavior difference and should be no runtime cost difference between the two.
My guess is that the static analysis tool complains about the
while
loop being controlled by a constant in the simpler case and doesn't when0,0
is used. The customer's suggestion is probably just so they don't get a bunch of false positives from the tool.For example I occasionally come across situations where I want to have a conditional statement controlled by a constant, but the compiler will complain with a warning about a conditional expression evaluating to a constant. Then I have to jump through some hoops to get the compiler to stop complaining (since I don't like to have spurious warnings).
Your customer's suggestion is one of the hoops I've used to quiet that warning, though in my case it wasn't controlling a
while
loop, it was to deal with an "always fails" assertion. Occasionally, I'll have an area of code that should never execute (maybe the default case of a switch). In that situation I might have an assertion that always fails with some message:But, at least one compiler I use issues a warning about the expression always evaluating to false. However, if I change it to:
The warning goes away, and everybody's happy. I'm guessing that even your customer's static analysis tool would be, too. Note that I generally hide that bit of hoop jumping behind a macro like:
It might be nice to be able to tell the tool vendor to fix the problem, but there might be legitimate cases where they actually do want to diagnose a loop being controlled by a constant boolean expression. Not to mention the fact that even if you convince a tool vendor to make such a change, that doesn't help you for the next year or so that it might take to actually get a fix.