INTRODUCTION:
An uninitialized variable has an undefined value, often corresponding to the data that was already in the particular memory location that the variable is using. This can lead to errors that are very hard to detect since the variable’s value is effectively random, different values cause different errors or none at all. These errors may be noticeable as a test-case that intermittently fails (never a good sign.) Debugging these types of errors is never fun and can be both tedious and time consuming.
Many coding standards or certification standards have rules around uninitialized variables. For example MISRA C:2012 covers it in 9.1, CERT-C in EXP33-C and there are multiple CWEs like CWE-457 that cover uninitialized variables. Mitigating these errors is important since they manifest in other types of errors such as CWE-131 (incorrect calculation of buffer size) and CWE-190 (integer overflow or wraparound.)
Related :
- Accelerating automotive software safety with MISRA and static analysis
- Measuring the value of static analysis deployments
- What’s New in CodeSonar 4.5?
No problem, my compiler catches these errors. Right?
Compilers can catch simple cases of uninitialized variables; see for example the flag -Wuninitialized for GNU GCC. In addition, embedded development tools vendors such as IAR Systems provide static analysis tools within the IDE for their particular embedded target platforms. However, compilers and source-unit level static analysis don’t catch more complex cases where a variable is passed by reference into another function that is expected to initialize the variable. That would require deeper analysis of possible execution paths, the type of whole program analysis that an advanced static analysis tool provides.
When performing whole program analysis, it is important to analyze the same code that is compiled into the final shipping product. IAR Systems provides compilers that are deeply optimized for embedded hardware, such as the STM32Cube from STMicroelectronics. The IAR Embedded Workbench IDE includes both an optimizing compiler and the C-STAT static analysis tool. C-STAT will find uninitialized variables inside your compilation units quickly, and is useful while you are developing the code. However, as the enclosed video demonstrates, advanced static analysis tools like CodeSonar can add whole program analysis. For this task, the tool needs to be able to understand the language extensions that the compiler uses, and not only analyze compilation units within the program and the application logic. Instead, the analysis needs to extend into the hardware abstraction layer, and if possible, even the OS.
A good analogy for the different between these static analysis workflows is the difference between unit testing and system testing. C-STAT performs quick static analysis in more of a unit-testing type of way, where CodeSonar performs advanced, whole program static analysis analogous to system-testing. Both types of testing and both types of static analysis are important for software development projects. It is important to keep in mind though, that static analysis can be used a lot earlier in the software development life cycle compared to unit- and system-testing.
Eliminate the Ticking Time Bombs
Uninitialized variables are like little time bombs, ready to go off when you make an architectural change and memory layout changes, when the code is refactored, or when extending an existing system with new functionality. They can occur in mainline code, but also in error-handling code, making them especially difficult to find. The result can be erroneous output or it can lead to incorrect behavior as well as system crashes.
Advanced static analysis tools like CodeSonar are very helpful in finding possible uninitialized variables, as demonstrated in video below. Uninitialized variables are discovered in analyzed applications by searching on ‘class=”Uninitialized Variable”’ in the analysis results in the CodeSonar web-based hub.
Thanks for reporting a problem. We’ll attach technical data about this session to help us figure out the issue. Which of these best describes the problem?
Any other details or context?
