What is do { } while(0) in macros and should we use it?

The sole purpose of the do { } while(0) is to write macros that accommodates to all manner of diverse coding styles. It is quite common not to use braces after if statements, so this is a common coding style:

if(bad)
  HCF(0xDEADBEEF);
else
  printf("good");

If we only used braces as in the first example in the question, it would expand to:

if(bad)
{
  fprintf(stderr, "halt and catch fire"); 
  exit(0xDEADBEEF);
}; // oops
else
  printf("good");

The semicolon written during macro invocation would result in a syntax error "else without previous if" etc. The purpose of do { } while(0) is to swallow up that stray semicolon. Note the lack of semicolon after while(0) which is otherwise the custom in do-while loops:

#define HCF(code) do { fprintf(stderr, "halt and catch fire"); \
                       exit(code); } while(0) 

expands to

if(bad)
  do
  {
    fprintf(stderr, "halt and catch fire"); 
    exit(0xDEADBEEF);
  }while(0);
else
  printf("good");

Which is perfectly valid C. If your purpose was to write a widely portable macro as part of a library or similar, you can probably stop reading here and feel all smug about this neat trick.

However, if your purpose is to write safe C code and only allow safe C code to compile, there is reason to question the purpose of do { } while(0).

Several industry coding standards (MISRA-C, CERT C etc) heavily discourage the style of using control/loop statements without braces {}, since it enables us to write common bugs such as this one:

if(bad)
  fprintf(stderr, "halt and catch fire"); 
  exit(0xDEADBEEF); 

Where the indention fools us to believe that exit is only executed if bad is true. These kind of bugs are particularly common during code maintenance.

One of the most expensive bugs in software history is the infamous "Apple goto fail", which was caused by some version control hiccup. If this code had gone through static analysis before production and the company coding standard enforced {} after each if statement, the bug would have been found.

So there are good reasons to always enforce {} in your coding style. I was once in favour of the if without braces style myself, since it makes the code more compact. However, I have converted to the "always use {} camp" over the years. Other seasoned C programmers I have spoken to have done the same, coming to this conclusion by themselves, rather than having it enforced by a coding standard, after having written numerous missing {} bugs.

So lets assume that we want to use the {} style, always. The do { } while(0) macro style then suddenly turns harmful - because it will allow control/loop statements without braces to compile. Whereas the {} macro style will yield a compiler error because of the stray semicolon - and now we realize that's a good thing.

posted almost 4 years ago

CC BY-SA 4.0

4y ago

Lundin‭

8948 reputation 36 122 1027 166

Reasons to use the construct #define FOO(x) do{...} while(0);:

1. As mentioned above, doing so solves the problem of

   if (...) FOO(y);
   

2. You can declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which FOO(x) gets expanded.

   Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happen as many times as the macro argument appears in the body!

   Declaring a variable inside a do {} block prevents this, as follows:

   #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
   

   Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc.

3. Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.

posted almost 4 years ago

CC BY-SA 4.0

1y ago by Karl Knechtel‭

Pete W‭

51 reputation 0 1 5 7