...
cpptestcli -data /path/to/workspace -resource "ProjectToTest" -config team://DataFlowAnalysis -publish
See Testing from the Command Line Interface for more details on configuring batch-mode tests.
| Anchor | ||||
|---|---|---|---|---|
|
...
Test configurations that trigger violations can be opened from the Quality Tasks view: Right-click on a violation and choose View Test Configuration.
Quickly accessing test configuration from the violation is useful for group architects who are customizing tests and want to quickly disable rules that aren’t applicable. Developers importing results from a server-based run may also need to open and review test configurations that trigger violations.
...
In the Quality Tasks view, each Flow Analysis violation is represented by a hierarchical flow path that precisely describes the code that leads to the identified problem. Each element in the path is a line of code that is executed during runtime. If a flow path has a call to a function, the element representing that function call is a node whose subnodes represent execution flow within the called function. The final element in the execution path is always the point where the bug manifests itself. The complete path is presented in order to explain why there is a bug at the final point.
Flow path elements are marked with icons that help explain exception handling behavior. If a path has a throw statement or a call to a function that happens to throw an exception on that path, the path element corresponding to the throw statement or the function call is marked by a red sphere. This red sphere indicates that the flow does not proceed as normal.
Each element in the flow path has a tool tip that describes the variables related to the violation. For example, an "Avoid null pointer dereferencing" violation description contains annotations describing which variables contain null values at which point in the flow path. To view a tool tip for a flow path element, place your cursor over it.
The elements of the flow path that are marked by the information icon have tool tips to help you analyze the flow that leads to the detected problem. Hover over an element to display the tool tip.
If you want to navigate through the code related to a reported execution path, use the Next Task Element and Previous Task Element buttons in the Quality Tasks view toolbar.
...
You can easily access the violation cause and violation point by right-clicking a reported violation (the node with the yellow caution icon), then choosing the appropriate command from the shortcut menu (either choosing Show Violation Cause or Show Violation Point. For example, an "Avoid null pointer dereferencing" rule violation has the commands Show Violation Cause (Source of Null Value) and Show Violation Point (Null Pointer Dereferencing Point) in order to help you understand why the exception may occur in the code.from the shortcut menu.
The corresponding code will be highlighted in the editor:
Highlighting the Source Code Referenced by a Violation Message
To highlight the source code referenced by a Flow Analysis violation message, simply double-click that message. An editor will open with the source code corresponding to the violation selected and the flow path highlighted in light blue. Any line at which an exception is thrown is marked with pink. All the lines which are important for the violation (violation cause, violation point, critical data flow) are highlighted in a dark color.
If you want to navigate through the code related to a reported execution path, use the Next Violation Element and Previous Violation Element buttons in the Quality Tasks view toolbar.
...
Here is an example of the detailed view:
Here is an example of the compact view for the same violation:
Viewing Detailed Paths in the Editor
...
- Do not report violations when cause cannot be shown: Determines whether Flow Analysis reports violations where causes cannot be shown.
Some Flow Analysis rules require that Flow Analysis checks all the possible paths leading to a certain point and verifies that a certain condition is met for all those paths. In such cases, a violation is associated with a set of paths (whereas in simple cases, a violation is represented by only one path). All of the paths in such a violation end with the violation point common to all the paths in the violation. However, different paths may start at different points in code. The beginning of each path is a violation cause (a point in code which stipulates a violation of a certain condition later in the code at the violation point). If a multipath violation's different paths have different causes, Flow Analysis will show only the violation point (and not the violation causes).Violations containing only the violation point may be difficult to understand (compared to regular cases where Flow Analysis shows complete paths starting from violation causes and leading to violation points). That’s why we provide an option to hide violations where the cause cannot be shown.
See the example below for additional details.
- Do not report more than one violation per point: Restricts reporting to one violation (for a single rule) per violation point. For example, one violation will be reported when Flow Analysis detects a potential null dereference with multiple sources of the null value. When verbosity is set to this level, Flow Analysis performance is somewhat faster.
- Do not report violations whose paths pass via inline assembly code: Prevents the reporting of violations whose paths pass via inline assembly code instructions.Level of reporting similar violations (i.e those that share a violation point, or both the point and the cause): Allows you to determine whether Flow Analysis reports all the violations that it can find in the analyzed code or if it hides some of them. Available options are:
- Report all similar violations: Reports all identified Flow Analysis violations.
- Do not show more than one violation with the same cause and violation point: Prevents the reporting of duplicate Flow Analysis violations. Duplicate violations are those that share the same violation cause and the same violation point (even though their flow paths may be different). Do not show more than one violation per suspicious point: Restricts reporting to one violation (for a single rule) per suspicious point. When verbosity is set to this level, Flow Analysis performance is somewhat faster.
Example - Impact of "Do not report violations when cause cannot be shown"
...