Static analysis

Notes

Sound analysers that prove the absence of a defect class exist but are slow, so most projects use heuristic tools plus review.

Overview

Static analysis is the automated inspection of source code, or compiled binaries, without running it, to find defects such as null pointer use, buffer overflows, uninitialised variables, data races and breaches of coding standards. In embedded and safety-related software for chips and devices it is a standard practice, often required to show compliance with coding rules such as MISRA C.

How it works

Static analysis tools parse code into an internal model and reason about all the paths it could take. Simple checkers match patterns, such as a forbidden function or construct. Deeper analysers track data and control flow across functions and files, and some use abstract interpretation to compute what values variables could hold, proving that certain errors cannot happen or showing how they could.

Tools trade depth against speed and noise. A shallow tool runs quickly but misses defects; a deep one finds more but may report false positives that engineers must review. Teams tune rules, suppress reviewed warnings with justification, and run analysis automatically on every change.

Coding standards give the rules a target. MISRA C and MISRA C++ define guidelines for safer use of these languages in critical systems, widely used in automotive and beyond, and CERT secure coding standards focus on security. Functional safety standards such as ISO 26262 recommend static analysis among the methods for software verification. The same idea, analysing code without executing it, also appears in hardware as lint for RTL.

Examples

• Checking automotive microcontroller drivers against MISRA C rules before each software release.
• A deep analyser finding a possible buffer overflow in boot code that testing never triggered.
• Reviewing and documenting justified deviations from a coding rule for a safety assessor.
• Running static analysis on every code change submitted to a firmware repository.

Why it matters

Defects found by static analysis are among the cheapest to fix, and in safety and security work the reports form part of the evidence for certification. Embedded software engineers run it daily, software quality engineers and functional safety software engineers define the rules and review deviations, and chip vendors run it on drivers, firmware and SDKs they ship to customers.

In the chip lifecycle static analysis runs continuously on firmware and software from the first code through every release.

Related terms

• MISRA C
• CERT C
• ASPICE
• MC/DC

Where it appears on the Hub

Used on 33 pages of the Hub. In each group, the pages that mention it most come first.