Identification

• The exact set of properties depends on the class of the warning.
  • The warning class name is always included.
  • Location information is included in a way that provides some flexibility for code changes between analyses.
    • For warning classes associated with execution paths, the portion of the call stack that lies within the core path is included in the fingerprint.
    • Line content (but not the precise location of that line) is included in the fingerprint. In particular, file names, directory names, and line numbers are not included.
• If two warning instances (on the same hub) have the same Group ID, they will have the same fingerprint.
• If warning group sharing is ON (and has always been so) then there is a 1:1 correspondence between Group ID and Fingerprint across the hub.
• If warning group sharing is OFF, two warnings in different projects on the hub must always be in separate warning groups and so can never have the same Group ID. There will be a 1:1 correspondence between Fingerprint and Group ID within each project on the hub.

• global scope: multiple projects can have instances of this warning group
• project scope, with respect to a specific project P: instances of this warning group can only be issued by analyses of P.

• warning class
• file
• procedure
• line content (but not the precise location of that line)

Classification

The GUI and warning search language provide direct access to several Warning Class properties:

Score is a composite of several factors:

• The likelihood that the warning represents a true positive.
• The severity of the problem being warned about; in particular, whether it is security-related.
• The complexity of the warning, with more-complex warnings generally receiving lower Score values than less-complex warnings - more-complex warnings take longer to review and diagnose, so it is typically preferable to address less-complex warnings first.

Score is calculated directly from Rank:

Score Coloring

When the Score column is displayed in a table of warnings (in Analysis: Warnings Tab, Warning Cluster, or Warning Search Results), each Score cell has a colored background. The color reflects a Score partitioning whose default "pivots" are 21 and 56, meaning that coloring is applied as follows.

To change the boundaries ("pivots") of these color bands:

1. Shut down the hub.
2. Edit $CSONAR/codesonar/py/hub/build_options.py to change one or both of the values in the score_color_pivots tuple.
3. Save your changes.
4. Restart the hub.

The score coloring in warning tables will now reflect your updated pivot values.

With factory settings, the CodeSonar Web GUI presents Score (computed as 100-Rank) rather than Rank, but you can view Rank values by adding the Rank column to any table of warning classes. Rank itself is unlikely to be interesting unless you are implementing a custom warning class and want to set up its Rank calculations: these will determine the Scores of the resulting warnings.

Rank is a composite of several factors:

• The likelihood that the warning represents a true positive.
• The severity of the problem being warned about; in particular, whether it is security-related.
• The complexity of the warning, with more-complex warnings generally receiving larger Rank values than less-complex warnings.

Rank is determined as follows:

1. CodeSonar determines the base rank for the warning.
   • For warning classes defined using configuration file BAD_FUNCTION_* rules, the base rank is specified by BAD_FUNCTION_BASE_RANK.
   • For warning classes defined using configuration file BAD_MACRO_* rules, the base rank is specified by BAD_MACRO_BASE_RANK.
   • For warning classes defined using configuration file METRIC_WARNING_* rules, the base rank is specified by METRIC_WARNING_BASE_RANK.
   • For warning classes defined using the CodeSonar Plug-in API, the base rank is specified as an argument to the warning class creation function.
   • For other built-in warning classes, the base rank is computed internally by CodeSonar.
2. Starting with this base rank, CodeSonar applies all the adjustment rules in $CSONAR/codesonar/py/hub/codesonar/rank_rules.py whose @pattern matches the properties of the warning. When TAINT_RANK_BONUS=Yes, CodeSonar also applies an adjustment if values relevant to the warning are tainted.
3. The resulting value is the Rank.

select cs_warningclass.label_xml, 
       min(cs_warninginstance.rank),
       avg(cs_warninginstance.rank), 
       stddev(cs_warninginstance.rank),
       count(cs_warninginstance.rank) 
  from cs_warninginstance,
       cs_warninginstdata, 
       cs_warningclass 
  where cs_warninginstance.data_id=cs_warninginstdata.id and
        cs_warningclass.id=cs_warninginstdata.warningclass_id and
        analysis_id=5
  group by cs_warningclass.label_xml 
  order by min(cs_warninginstance.rank)

• If the instance Warning Class is a C/C++ parser warning class, parse error status is determined by the parser: for a given warning class, there may be some warning instances that are parse errors but other warning instances that are not.
• For warnings that do not belong to a C/C++ parser warning class, Effective Parse Error? is always "false".

• If the instance Warning Class is a C/C++ parser warning class, the parse diagnostic severity is one of: {"remark", "warning", "cmdline_warning", "discretionary_error", "error", "catastrophe", "cmdline_error", "internal_error"}.
  The severity is determined by the parser. Different instances of the same warning class may have different severity values.
• For warnings that do not belong to a C/C++ parser warning class, Parse Diagnostic Severity is always "undefined".

Analysis Details

Note that this value never changes, even if the analysis that issued the first warning is subsequently deleted.

Source Details

For warnings associated with execution paths, we refer to the path fragment covered by the Listing as the core path. This is the sequence of calls and program statements whose execution will trigger the warning. Users can examine the possible call sequences leading into the core path with the Explore Callers and Search Callers functionality.

Conditions

User-Controlled

Use the Settings page to specify a default priority for new warnings.

Use the Settings page to specify a default state for new warnings.

• The most recent user edit to group information.
• The date and time at which the most recent warning instance in the group was issued.