Investigating warnings

When the analysis is done (or while it is still running) it is time to look at the results. This page explains how to read a warning, how to decide if it is a real bug, and what you can do with it.

Reading a warning

Click a warning in the results list. The lower part of the window then shows:

the id of the warning, for example arrayIndexOutOfBounds. The id identifies the kind of problem. Search for it in the Cppcheck documentation or on the internet to learn more about it,
the CWE number, if there is one. CWE (Common Weakness Enumeration) is a standard list of software weaknesses. Look it up at cwe.mitre.org for a general description of the problem,
the full message. It can be longer than the summary in the list,
the source code with the line of the warning highlighted.

In the example above Cppcheck says that buf[16] is accessed at index 16. The array has 16 elements, so the valid indexes are 0 to 15. The loop condition i <= BUFFER_SIZE should be i < BUFFER_SIZE.

Notes: the path to the bug

Many warnings have notes. Click the arrow in front of the warning to see them. Notes show the steps that lead to the problem, in order, for example:

Assuming that condition 'i<=16' is not redundant   (line 9)
Array index out of bounds                         (line 10)

Click a note to show its line in the code view. For a bug that depends on values, the notes usually tell you where the value comes from, which conditions Cppcheck assumes, and where the bad value is used. Follow the notes to understand the warning.

A note like Assuming that condition 'x' is not redundant means that Cppcheck uses the condition in your code as a hint about possible values. For example, if the code checks if (p == NULL) after it has already used p, then either the check is not needed or the code can use a null pointer. Cppcheck warns because one of them must be wrong.

Is it a real bug?

Cppcheck tries to avoid false warnings, but no static analysis tool is perfect. To decide if a warning is right:

Read the message and the notes, and look at the code they point to.
Think about the values Cppcheck mentions. Can they really happen? Look at the callers of the function if needed.
Check if Cppcheck may be missing information. Warnings in code that uses macros or types that Cppcheck could not see, because an include path is missing, can be wrong. Look for missingInclude information messages and fix the include paths in the project.
Check if a library configuration is missing. If your code calls a function that never returns (like a fatal error handler) and Cppcheck does not know that, it may warn about code after the call. Select the library in the project or write a configuration for your own functions. See Libraries.

Even if a warning is not a bug today, it can point to code that is hard to understand or easy to break. Many developers prefer to change the code so that the warning goes away, instead of suppressing it.

If you are sure Cppcheck is wrong, suppress the warning (see Hiding and suppressing warnings). It is also very helpful if you report the false warning, with a small code example, at https://trac.cppcheck.net/ or in the Cppcheck forum.

Inconclusive warnings

Sometimes Cppcheck finds something suspicious but can not be sure that it is a bug. These inconclusive warnings are not shown by default. Enable Check for inconclusive errors also in the preferences to see them. An extra Inconclusive column then marks them. Expect more false warnings among them.

Where to start

The first analysis of a large project can give many warnings. Some tips:

Start with errors, then warnings. Use the severity buttons in the toolbar to hide the other severities.
Look at the information messages early. They are not bugs, but they tell you about problems in the configuration, such as headers that can not be found. Fixing them makes the other results better.
Sort by the Id column to handle one kind of warning at a time. If one kind of warning is wrong everywhere, it may be a configuration problem.
Use the quick filter to find warnings about a function, a variable or a file.
With a build dir, sort by Since date to see the newest warnings first. New warnings are the easiest to fix, because the code is fresh in your mind.
Use tags to remember what you have looked at.

Opening the code in an editor

Double-click a warning, or select it and press Enter, to open the file in your default editor at the line of the warning. You can also right-click a warning and choose an editor at the top of the context menu.

Editors are configured in the preferences on the Applications tab. On some systems the GUI finds installed editors automatically.

If the file is not found, for example because the results were loaded from an XML file created on another computer, the GUI asks you to select the folder where the file is.

The context menu

Right-click one or more selected warnings to get the context menu. Select several warnings with Ctrl+click or Shift+click.

Command	Description
(editors)	Open the file of the warning in this editor.
Recheck N file(s)	Analyze the selected files again. Select file items (the top level items in the list) to enable this. Useful after you have fixed something in a file. Not available while an analysis is running or for results loaded from an XML file.
Copy	Copy the selected warnings, notes or file names to the clipboard as text, in the format `file:line:column:severity: summary [id]`, followed by one line for each note. Paste it in a bug report or a chat.
Hide N result(s)	Hide the selected warnings until the next analysis. See Hiding warnings.
Hide all with id	Hide all warnings with the same id as the selected warning, until the next analysis.
Suppress selected id(s)	Suppress all warnings with the ids of the selected warnings, in all files. The suppression is saved in the project file, so the warnings are not reported again. See Hiding and suppressing warnings.
Open containing folder	Open the folder of the file in your file manager.
Tag	Give the selected warnings a tag. Only shown if the project has tags. See Tagging warnings.

Analyzing again

After you have changed the code:

Right-click a file in the results list and choose Recheck to analyze just that file again.
Use Reanalyze all files in the toolbar to analyze everything again. With a build dir only changed files are analyzed again, so this is fast.
Use Analyze > Reanalyze modified files (Ctrl+R) to analyze only the files that changed since the last analysis. See The main window for when this is available.

Previous: Project files | Next: Severities and report types