{
    "codechecker.executor.runOnSave": true,
    "codechecker.executor.arguments": "--config ${workspaceFolder}/app/config/codechecker.yml --skip ${workspaceFolder}/app/config/skip.codechecker",
    "codechecker.backend.compilationDatabasePath": "${workspaceFolder}/build/compile_commands.json"
}

After applying this configuration in the file .vscode/settings.json, CodeChecker will run automatically every time you save a file. If you also have the auto-save feature enabled, the analysis will take place in the background while you are typing, which streamlines your workflow.

For executor arguments, you can pass the same files that are used in CMake for CodeChecker. This ensures perfect configuration synchronization. Finally, remember to specify the location of the compilation database, which in our case is the file compile_commands.json.

Enjoy a smooth code checking process!

Practical Applications

The first part of the article focused mainly on the configuration and use of CodeChecker. In this section, we will discuss topics of practical relevance to real-world projects. These topics include:

• Work with a remote CodeChecker server in a Continuous Integration (CI) environment,
• Integrate CodeChecker with any pre-commit checker tool,
• Implementation of automatic repair functions,
• Running CodeChecker on projects outside the Zephyr ecosystem.

CodeChecker and CI

CodeChecker has the ability to upload its results to a remote server. This section focuses on running a local server to upload the latest analysis results. In addition, I will outline the enhanced functionality available on the server compared to locally generated reports.

To begin, start the server by running the following command in a separate terminal:

CodeChecker server

Then check the connectivity by opening the address in your browser:

http://localhost:8001/Default/

If everything works correctly, run the analysis again with an additional flag to redirect the results to the server. Use the following command:

west build -b qemu_cortex_m3 app --pristine -- -DZEPHYR_SCA_VARIANT=codechecker -DCODECHECKER_STORE_OPTS="--name;example;--url;localhost:8001/Default"

When you refresh your browser, you will notice that the "Default" product has recorded a new run since the last analysis. Go to the "Default" product > "Statistics" tab to see a graph illustrating violations over time. The amount of information provided is of course limited, having only one iteration.

From a server perspective, you have access to the same statistics as locally. However, with desktops you have the option:

• Track changes in the number of violations over time,
• Aggregation of statistics from many products in one place,
• Classify violations as "confirmed errors," "false positives" or "intentional."
• Conduct discussions on violations using your personal account.

It's worth a try, especially if you have CodeChecker configured in your project. Starting and deploying the server is relatively easy.

Blocking commits for unresolved violations

In the previous section, you learned about the different states a breach can be in. These states include:

• Confirmed error
• False positive
• Purposeful
• Unsolved

In my opinion, the most dangerous condition is unresolved. Ideally, such problems should not exist at all. Why? Because what does it mean? Is anyone aware of the existence of such a violation? Or is it not relevant? Or maybe it is, and we are dealing with serious problems. I prefer to be clear on this issue. That's why I'm glad that any violation can be in one of these states.

However, let's get to the point. Presumably, you want to check, whether in the pre-commit hook or on continuous integration (CI), that there are no unresolved violations. To achieve this, you need to parse the generated report using a command similar to the following:

CodeChecker parse build/sca/codechecker/codechecker.plist --review-status unreviewed

This command should return a return code of 2, which means that at least one report has been generated by the analyzer. A return code other than 0 should also be understood by any pre-commit or CI tool, allowing such a command to be used to block a commit or CI build. However, do we really want to push this violated code to the main branch? Naturally, such situations will happen. What then? Well, I recommend marking this violation as confirmed in the code so that you can deal with it when the time is right. You can do this by adding a comment similar to the following:

// codechecker_confirmed [all] this code intentionally contains violations
while (1) blink_led();

This way, the parsing command will succeed, and you will still be able to see the violation both in your integrated development environment (IDE) and on a remote desktop. Doesn't this create a win-win situation?

Auto Repair

Style checkers often offer an option to automatically correct violations. This is also the case with ours. Required corrections include adding brackets after the loop while and replacement 1 at true. Sounds simple, right? Of course. Using CodeChecker can take care of this matter effortlessly. Just run the following command and all the corrections will be applied, leaving CodeChecker satisfied:

CodeChecker fixit build/sca/codechecker/codechecker.plist --apply

CodeChecker in the Zephyr Free Project.

Wow, everything sounds impressive so far, but what if you're not working on a Zephyr project? Don't worry, you are not lost! A very useful feature is the ability to do a quick analysis in CodeChecker. How does it work? It analyzes the ongoing build process or compilation database to perform analysis based on this information. Let's dive into it!

#include <chrono>
#include <iostream>
#include <thread>
namespace {
    const auto BLINK_DURATION = std::chrono::milliseconds(1000);
    void blink_led() {
        std::cout << "LED blinks" << std::endl;
        std::this_thread::sleep_for(BLINK_DURATION);
    }
}
int main(void)
{
    while (1) blink_led();
    return 0;
}

blink: main.cpp
	g++ -Wall main.cpp -o blink

CodeChecker check --config ../app/config/codechecker.yml --build "make"

> CodeChecker check --config ../app/config/codechecker.yml --build "make"
...
[INFO 2024-07-09 09:34] - ----=================----
[INFO 2024-07-09 09:34] - Analysis length: 0.8173582553863525 sec.
[STYLE] /repos/code-checker-example/non-zephyr-app/main.cpp:17:12: implicit conversion 'int' -> bool [readability-implicit-bool-conversion].
    while (1) blink_led(); 
           ^
[STYLE] /repos/code-checker-example/non-zephyr-app/main.cpp:17:14: statement should be inside braces [readability-braces-around-statements].
    while (1) blink_led(); 
             ^
Found 2 defect(s) in main.cpp
...