Catching Defects Before They Fly

Consider this scenario: You're climbing in clear weather, and everything is nominal. You start a gentle right bank, and as the angle increases, the flight controls stop responding. The airframe is fine, and so is the pilot. The software is what failed.

Luckily, this scenario is made-up, but it could happen. We replay this scenario in our latest CodeSonar demo, which runs on the open-source FlightGear simulator. To be upfront: we injected the defect on purpose. It's a bug planted in real code, so we could show how CodeSonar finds it. Real defects of this kind ship regularly, though, because nobody caught it during development.

Find the bug

CodeSonar flags the problem as a null pointer dereference, one of the most common defect classes in C and C++. The warning report lists the full path through the source code:

• The trigger: a string copy that uses the pointer.
• The root cause: an earlier event where that same variable is set to null.
• Compliance context: a link showing which standards the warning maps to, including CWE, MISRA, and DISA. You can generate reports on these violations directly.

Triaging the warning

After reviewing a warning, you annotate it: true or false positive, priority, and fix status. In this case, it's clearly a true positive.

CodeSonar stores those annotations in a database and stores them across analyses. If you mark a warning as ignored, it stays suppressed in future runs, even if the code moves. You don't need suppression comments in the source. This is important, as modifying source code often triggers testing obligations.

This matters because the full FlightGear analysis produced 3,364 warnings, and we planted only one of them. In a codebase that size, persistent triage is what makes the tool usable over time.

A real finding: an interprocedural resource leak

The second example wasn't planted. CodeSonar found a possible resource leak in an error-handling path of FlightGear's bundled third-party IAX client library. Memory is allocated in one function, but an early-return error path in a different function means it's never freed.

This finding shows several important CodeSonar capabilities:

• Path highlighting. CodeSonar marks the exact lines on the path that leads to the defect, so you can see whether it depends on a particular condition, an error routine, or something else.
• Interprocedural analysis. The line that triggers the warning is in one procedure, but another procedure is what makes the leak possible. Tools that analyze one function at a time miss defects like this.
• Variable tracing. Hovering over a variable highlights every use of it, and a side panel shows where it's defined, read, and written. This works for both local and global variables.
• Taint tracking. CodeSonar shows whether a variable may hold unvalidated external data.

Not just Aerospace

A flight simulator makes a vivid demo, but these defect classes appear wherever C and C++ run critical systems: automotive, medical devices, industrial automation, defense, transportation, and semiconductor processing. Finding them during development costs far less than fixing them in the field.

Contact AdaCore to see how CodeSonar and our other tools can help your team.