Issue states

Issue states are read-only indicators that trace the history of an issue from the time it is first detected to the time when it is fixed.

• When issues are first detected in a build, they are labeled New.
• Issues that existed in the previous build but not in the current build are labeled Fixed.
• Issues detected in both the current and the previous build are labeled Existing.

States are shown in Validate. (The issue origin, not state, is shown in desktop analysis results.)

There are two scenarios in which state is used in Validate: searching and build comparison. By default, a Validate search returns only New and Existing issues, not Fixed. When comparing two builds, the state is determined based on the builds you're comparing.

It's easiest to explain the three possible states with a build comparison example. Say we're comparing Build_1 with Build_3. It's important to note that these two builds are not consecutive.

This example finds issues detected in Build_3, but not in Build_1. This does not mean that these issues were introduced in Build_3; they may have been introduced in Build_2:

diff:build_1,build_3 state:New

This example finds issues detected in both Build_1 and Build_3:

diff:build_1,build_3 state:Existing

This example finds issues detected in Build_1, but not in Build_3. This does not mean that these issue were fixed in Build_3; they may have been fixed in Build_2:

diff:build_1,build_3 state:Fixed

Migration recommendation: We recommend running your final pre-upgrade analysis and your first Klocwork 2024.3 analysis on identical source code, and then comparing the two builds, so that you can properly assess the changes in your analysis results due to improvements in our analysis engine.