Eight tips for using Assert debugging in C language

The assert (assertion) macro in C is one of the best debugging tools that embedded software developers can use. Although assert is powerful, I rarely see it implemented, and in some cases where it is used, its implementation is either flawed or incorrect. The following tips will not only help clarify when and where to use assert, but also explain 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 intent. The clearest definition of assertions I have seen is this:

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

Developers who want to understand the above assertion definition should pay attention to the following three key points:

• Assertions evaluate whether an expression is true or false

• Assertion is an assumption of the state of a system at a point in the code

• Assertions verify that system assumptions, if not true, indicate a flaw in the Code 2: Prerequisites for using Assert validation functions (entry parameter validity check)

Assertions are well suited to a contractual design environment in which 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 as an example:

Figure 1: Prerequisites for functions

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

Figure 2: Applying assertions to function prerequisites

In an event that 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 goes wrong immediately, rather than after a period of time. Tip 3: Use the Assert validation function's post condition (Export data validation check)

Assertions can also be used to validate assumptions about the output of a function in a contract design environment. For example, if the previously defined System_stateset function returns a systemstate variable, the developer can expect it to also be within the expected range. Assertions can be used to monitor for defects, as shown in Figure 3.

Figure 3: Applying assertions to function post conditions

Developers may feel that these checks are meaningless after viewing the above code. Just set up a good systemstate how will appear greater than System_state_max value it. The answer is that this really shouldn't happen, but sometimes it will change somehow, perhaps through interrupts or parallel threads, at which point the assertion can immediately mark the flaw. Tip 4: Don't use assert for error handling

After remembering the assertion definition, developers should remember 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 simply because there is invalid input does not mean that there is a flaw in the code. Error handling should be separated from the search for defects. A typical example of error-using assertions is to check the file's pointer when trying to open a file for reading, as shown in Figure 4.

The improper use of the figure 4:assert

The reader can see clearly that the result of an attempt to open a file is related to the state of the file system and the user's data, but not to the flaw in the code. Developers should write error handlers instead of assertions so that when a file does not exist, the error handler can use some of the default available data to create it so that subsequent code continues to operate. skill 5:assert is only meaningful for development and cannot be used in production

The original intention of developing an Assert macro is to enable it during development and to disable it when it is produced later. You can activate and disable assert with the NDEBUG macro. Correctly implemented assertions should have no effect on embedded systems after they are disabled.

The problem is that if the test is done with the assertion enabled (this should be done to catch any bugs), disabling the assertion now will cause the delivered product to be in a different state than the test product. Assertions do occupy some code space, but more importantly, they require a small amount of clock cycles to evaluate their Boolean expressions. Disabling assert can have a significant impact on the timing of the execution of bare-metal systems with limited resources, resulting in new defects in the production system. The development team needs to determine whether it is worthwhile to risk closing assertions.

An alternative is to keep assertions in the active state and redirect their output to a system log. This ensures that any lingering flaws are easy to identify and can avoid aborting the system, which is not a smart move. Tip 6: Assertions are not allowed to have side effects

The default implementation of assert allows developers to include a section 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. But if an expression passed to assert has a side effect, that is, it alters the state of the embedded system, disabling the assertion changes the behavior of the system. Developers should make sure their expressions have no side effects, or they need to take the risk of adding a dormant time flaw in the system that only wakes up to the product code. Tip 7: Assertions should take up 1% to 3% of code

Each developer has its own ideas about how many assertions should be in the code base. One of the numbers agreed is that the assertion in the code base should be greater than 0. Assertions provide a good way for developers to discover a flaw in a code base at all times. Debugging is one of the most time-consuming and frustrating things in developing embedded systems. Regardless of whether the developer approves a ratio of 1%, 3%, or 5%, using assertions is certainly good for you and makes it a bit more interesting to develop embedded software. Tip 8: Use assertions as executable code comments

Assertions can generate excellent annotations. Writing an excellent expression tells the developer exactly what is expected to happen at a given point in the code. Developers should be able to do what they assert, helping people understand more clearly what is happening in the system, and thus helping to reduce defects. Summary

Assertions are an excellent tool, but there are too many embedded software developers who ignore this tool. The eight tips discussed in this article are just how to correctly use the tip of the predicate. Next, the reader can build and start using assertions in the test platform and study how they work in the actual embedded system.

PS:

for embedded research and development, data checking (the parameters passed in function calls, the results of entry parameters and operations in functions, and the results returned by function calls) are important and necessary, regardless of whether assertions are used or checked by themselves.