Assert() and other useful C language macros

June 17, 2013

Bernard Cole-June 17, 2013

In “Asserting failure,” Jack Ganssle’s most recent blog on, he presents a strong case – again – for the use of the assert( ) macro as a way for developers to use the C language to debug itself.

His column and a number of other contributions by a variety of authors are included in this week’s Tech Focus on “Getting assertive about code quality.” In addition, it also includes a number of articles and columns on other mechanisms, such as the X-macro  and the offset() macro, to achieve the same goals.

After researching the topic for this week’s Tech Focus newsletter, I went through the books on C programming and debugging I’ve read over the past decade or so and double checked how extensive the coverage of assert () and other useful C macros has been.

I was surprised at how little space was devoted to their use, given how extensively they are employed – and debated – within the programming community. Of the 18 C programming books I found in my library, only five or six discuss assert() or any of the other useful C macros, and half of those devote at most no more than one or two pages to the topics.

Only a few go into any useful detail. One is “Writing Solid Code,” by Steve Maguire, a supporter of its use. He devotes an entire chapter to how to deploy it effectively without any of the gotchas. The other, “Science of debugging” by Matt Telles and Yuan Hsieh, also covers its use in a chapter on Predebugging. More accurately, they expend much effort in detailing why its use is to be avoided.

Frankly, we do not see the value of asserts in producing quality software,” they write. “In fact, we believe that the usage of asserts is the mark of a lazy programmer. We believe that asserts can increase the odds of bug formation and introduction, and that usage of asserts should be avoided.

In addition to Maguire, coming to the defense of  assertions are Brian Kerrighan and Rob Pike (The Practice of Programming), and Steve McConnell (Code Complete). This dichotomy about their use is reflected in a number of technical conference and journal papers I have found on the web surveying the opinions of software developers, including:

Program assertions: What do practitioners want?”  and,
Runtime assertion checking in software development.” 

But in “Assessing the Relationship between Software Assertions and Code Quality,” the authors did more than survey the opinions of software developers. They did their best to pin them down to actual results. Then, using a variety of rock-solid statistical methodologies they have come up with an impressive positive correlation between assertion density and code quality: the more assertions, the better the quality of the code.

In the embedded environment, as Jack points out in several other blogs such as “A different take on asserts,” and “The use of assertions,” the doubts about it's use have included: 1) in many space and performance constrained 8 and 16 bit MCU designs, it takes up valuable memory space and 2) it imposes additional performance overhead on the MCU. But as he points out in his most recent blog, “with the proliferation of 32 bit MCUs most of these concerns go away.

If this shift is coming, it may mean serious consideration will be given in embedded designs to another related technique that Jack strongly supports: design by contract (DBC). Several especially useful blogs by Jack on the topic are:

Good contracts make good programs,”
Executing software contracts,”
Putting contracts out on bugs,” and
Contracts put the ‘I do’ in code.”

DBC is like assertions on steroids,” Jack writes.”With DBC one defines contracts, which are assertion-like statements about functions' input and output parameters (pre- and postconditions), as well as things that never change throughout the execution of the function (invariants). On their wedding day, the betrothed say ‘I do;’ they enter into a contractual arrangement that is an invariant underlying all of their future relationships.

I doubt the debate about the use of assertions (and other C macros) will go away any time soon. But I finally have come to see the benefits of their use when I read a comment made by Alan Turing in 1949 about the assertional method for proving correctness of programs.

"How can one check a large routine in the sense of making sure that it's right?” Turing asked rhetorically. “In order that the man who checks may not have too difficult a task, the programmer should make a number of definite assertions which can be checked individually, and from which the correctness of the whole program easily follows.

Interestingly, his comments were made at just about the time  John Von Neumann and a team of scientists and engineers at the Institute of Advanced Studies  were starting their work on the first computer based on Turing's concepts - and writing programs to run on it, without the aid of any of today’s modern debugging and static analysis tools. Site Editor Bernard Cole is also editor of the twice-a-week newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to, or call 928-525-9087.

See more articles and column like this one on Sign up for the newsletters. Copyright © 2013 UBM--All rights reserved.

Loading comments...