Eight tips for debugging with assert in the C language

ASSERT (ASSERT) macros in the C language are one of the best debugging tools available to embedded software developers. Although the assert is powerful, I seldom see it being implemented, and in some cases where it is used, its implementation is either flawed or incorrect. Here are some tips that will not only help clarify when and where to use assert, but also how to start using it correctly.

Tip 1: Remember the definition of assert

Assertions are a confusing topic for many developers, because many of them are used in a way that runs counter to their design intentions. The clearest definition of assertions I've seen is this:

"An assertion is a Boolean expression at a specific point in the program, unless the program has a flaw (BUG), otherwise its value will be true." ”

Developers who want to understand the assertion definitions above should be aware of the following three points:

• The assertion evaluates whether an expression is true or false

• Assertions are an assumption of the state of a system at a point in the code

• The assertion verifies that the system hypothesis, if not true, indicates that there is a flaw in the code

Tip 2: Prerequisites for using assert validation functions

Assertions are well suited to a contractual design environment where developers define the prerequisites for a function very clearly. Assertions can be used to check whether the input of the function satisfies the prerequisites. Take the code snippet shown in Figure 1 for example:

　　

Figure 1: Prerequisites for a function

The state input of the function should be within the defined range of system states. If state is not a valid status value, then it is not an error, it is a flaw! The assertion can be used to verify that states are valid assumptions, as shown in 2:

　　

Figure 2: Applying assertions to function prerequisites

In an event where state is not less than the maximum value, the assertion expression is evaluated as false and the program stops executing. Stopping program execution can make it easy for developers to see where the code is going wrong right away, rather than knowing it over a period of time.

Tip 3: Use Assert to verify the post condition of the function

Assertions can also be used to validate assumptions about a function's output in a contractual design environment. For example, if the previously defined System_stateset function returns a systemstate variable, the developer can expect it to be within the desired range as well. Assertions can be used to monitor defects, as shown in 3.

　　

Figure 3: Applying assertions to function post conditions

Developers who look at the above code may feel that these checks are meaningless. Just set up the systemstate how to appear more than the value of System_state_max? The answer is that it really shouldn't happen, but sometimes it somehow changes, perhaps by breaking or parallel threading, where the assertion can immediately flag the flaw.

Tip 4: Do not use assert for error handling

After remembering the assertion definition, developers should keep in mind that assertions are used to detect defects and cannot be used for error handling. Error handling is software designed to respond to incorrect user input and unexpected sequence of events. Errors are expected to occur in the system, but only because there is an invalid input that does not imply a defect in the code. Error handling should be separated from the defect search. A typical example of an incorrect use assertion is a pointer to a file that is checked when attempting to open a file for reading, as shown in 4.

　　

Improper use of Figure 4:assert

It is clear to the reader that the result of an attempt to open a file is related to the state of the file system and to the user data, but not to the flaws in the code. Developers should write error handlers instead of assertions so that when a file does not exist, the error handler can create it with some default data available for subsequent code to continue.

Skill 5:assert is only meaningful for development and cannot be used in production

The original intent of developing an Assert macro is to enable it during development and to disable it later in production. You can use the Ndebug macro to activate and disable assert. Correctly implemented assertions should have no effect on the embedded system after being disabled.

The problem is that if the test is done with the assertion enabled (in order to catch any flaws, it should), then disabling the assertion now causes the delivered product to be in a different state than the product being tested. Assertions do take up some code space, but more importantly, they require a Boolean expression that consumes a small number of clock cycles to evaluate them. Disabling assert can have a significant impact on the execution timing of bare-metal systems with limited resources, resulting in new defects in the production system. The development team needs to determine whether it is worth the risk of closing the assertion.

An alternative is to keep assertions in the active state and redirect their output to a system log. This ensures that any lingering flaws can easily be identified, and that it is not advisable to abort the system without stopping the system from running.

Tip 6: Do not allow assertions to have side effects

The default implementation of assert allows a developer to include a piece of executable code as part of a Boolean expression. For example, a state variable can be implemented as part of an expression and passed to assert. However, if the expression passed to assert has side effects, that is, it alters the state of the embedded system, disabling the assertion alters the behavior of the system. Developers should make sure that their expressions have no side effects, or they will have to risk adding a sleep-time flaw to the system that only wakes up the product code.

Tip 7: Assertions should account for 1% to 3% of the code

Each developer has its own opinion about how many assertions should be in the code base. One of the numbers that everyone agrees on is that the assertion ratio in the codebase should be greater than 0. Assertions provide a good way for developers to find a flaw in the code base at a time when it is found. Debugging is one of the most time-consuming and frustrating things in developing an embedded system. Regardless of the developer's approval ratio of 1%, 3%, or 5%, using assertions is certainly good for you and makes developing embedded software much more interesting.

Tip 8: Use assertions as executable code comments

Assertions can generate excellent annotations! Writing an excellent expression tells the developer exactly what to expect at a given point in the code. Developers should build the architecture they assert to help people understand more clearly what is happening in the system, and thus help to reduce defects.

Summary

Assertions are a great tool, but there are too many embedded software developers who neglect this tool. The eight tips discussed in this article are just the tip of the iceberg on how to correctly use assertions. The reader can then build and start using assertions in the test platform and examine how they work in the actual embedded system.

Advertising show http://www.biyinjishi.com/products/a35/
Outdoor Inkjet http://www.biyinjishi.com/products/a35-b3510/
LED Display http://www.biyinjishi.com/products/a35-b3515/
Door Head http://www.biyinjishi.com/products/a35-b3515/
Lightbox http://www.biyinjishi.com/products/a35-b3515/
logo Wall http://www.biyinjishi.com/products/a35-b3520/
AD Word http://www.biyinjishi.com/products/a35-b3520/
signage http://www.biyinjishi.com/products/a35-b3530/
logo http://www.biyinjishi.com/products/a35-b3530/
Exhibition Package http://www.biyinjishi.com/products/a35-b3535/
Conference http://www.biyinjishi.com/products/a35-b3535/
Exhibition Frame Leasing http://www.biyinjishi.com/products/a35-b3550/
Exhibition Fixture http://www.biyinjishi.com/products/a35-b3550/
Banner http://www.biyinjishi.com/products/a35-b3560/
Bunting http://www.biyinjishi.com/products/a35-b3560/
Banner http://www.biyinjishi.com/products/a35-b3560/
Wall Sticker http://www.biyinjishi.com/products/a35-b3570/
Car Sticker http://www.biyinjishi.com/products/a35-b3570/
Office Packaging http://www.biyinjishi.com/products/a50/

Eight tips for debugging with assert in the C language