Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

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

Parent

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

+9
−1

Background

I can see the need to use { } when implementing a function-like macro such as this one:

#define HCF(code) fprintf(stderr, "halt and catch fire"); exit(code);

Because if we use the following calling code

bool bad = false;
if(bad)
  HCF(0xDEADBEEF);
printf("good");

Then it will expand to

bool bad = false;
if(bad)
  fprintf(stderr, "halt and catch fire"); 
exit(0xDEADBEEF);
printf("good");

which was not the intention - it will now exit with an error code even though the program is working as intended.

So the correct way would be to write the macro like this instead:

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

Question

But I've come across macros that instead of just plain braces { } uses this:

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

This seems similar to { } but more obscure. What's the purpose of this do { } while(0) and why should it be used instead of { }?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+14
−1

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (2 comments)
General comments
Incnis Mrsi‭ wrote about 3 years ago

Suppose that the Apple coding standard enforced {} after each if. Surely would (a misleadingly indented) goto fail be detected because of this? Or would an unconditional { goto fail; } code recognized as problematical?

Lundin‭ wrote about 3 years ago

@Incnis Mrsi‭ Well it depends on if the braces would surround both gotos or just one. It wouldn't have passed manual code review either. If they had any resemblance of a quality coding standards, then none of the code from that link would be allowed. Not just the brace issue, but goto itself, assignment in conditions and other such signs of code smell.