...
Apart from the depth of analysis, Flow Analysis uses an additional timeout guard to ensure the analysis completes within a reasonable time. An appropriate strategy can be set by using the test configuration interface in DTP. Go to Report Center> Test Configurations> Static Analysis> Flow Analysis Advanced Settings> Performance> Strategy for Timeouts and choose one of the follow-ing following options by selecting a radio button:
...
In this mode, analysis data is written to disk. Swapping of analysis data uses the same persistent storage and is done in a similar process as incremental analysis. If the analysis is run on a large project, the analysis data that represents a semantical model of the analyzed source code may consume all the memory available for running Flow Analysis. If this occurs, Flow Analysis will remove from memory parts of the analysis data that are not currently necessary and reread it from disk later.
In general, we recommend runningCrunning C/C++testin test a large JVM heap configured with the Xmx JVM option. This is to minimize swapping, which results in greater performance. If sufficient memory is available, swapping of analysis data may be disabled, which may speed up code analysis.
...
Enable swapping of analysis data to disk: Enabledby Enabled by default. If this option is disabled, it may result in faster analysis, if you are running Flow Analysis analysis on small to moderate size projects that do not require a lot of memory or when plenty of memory is available (for example, for 64-bit systems).
...
- 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. - Do not show 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.
...
- Click the + button in the top row of the table.
- Click the arrow to expand the Functions that terminate application execution tab.
- Complete the table that opens; the table has the following columns:
• Enabled: Specifies whether a built-in or custom terminator should be considered during the analysis.
• Fully qualified type name or namespace (wildcard): Specifies the entity for a particular terminator. If this field is left empty, only the global function with the name specified in the 'Function name' column will be considered a terminator. For example: The field value may be "myNameSpace::myClass" if the terminator is declared in 'myClass' coming from the 'myNameSpace' namespace. Or, it may be "myNameSpace" if it is not declared in a type, but belongs only to the 'myNameSpace'.
• Function name (wildcard): Specifies the name of the terminating function.
• + definitions in subclasses: Indicates whether the terminating function definitions in subclasses should be considered terminating functions as well. Thisappliestobothinstanceandnon-instancefunctionsThis applies to both instance and non-instance functions, and makes sense only if its fully qualified type name is specified.
...
- Enabled: specifies whether the sleep function should be considered during analysis.
- Fully-qualified type name or namespace (wildcard): the fully-qualified name of the type or namespace where the function is declared. Use '*' if you want to describe a function declared in any type or namespace, or a global function declared outside of any type.
- Function name (wildcard): the name of the sleep function. '*' can be used to denote any num-ber number of any symbols.
- + definitions in subclasses: a check box that indicates whether the definitions (of the function with the given name) in subclasses should be considered sleep functions as well. Note that this applies to both instance and static functions.
...
- Enabled: specifies whether the allocator should be considered during analysis.
- Fully-qualified type name or namespace (wildcard): the fully-qualified name of the type or namespace where the function is declared. Use '*' if you want to describe a function declared in any type or namespace, or a global function declared outside of any type.
- Function name (wildcard): the name of the allocating function. '*' can be used to denote any number of any symbols.
- Resource parameters: specifies that the function allocates a resource in one or more of its parameters. In this case, either specify a 1-based number of the parameter that is allocated by the function, or use '*' to denote that all of the parameters are allocated.
- + definitions in subclasses: a check box that indicates whether the definitions (of functions with the given name) in subclasses should be considered allocators as well. Note that this applies to both instance and static functions.
- "this" object is a resource: a check box that indicates that the function allocates a resource in the object on which the function is called.
- Returns a resource object: a check box that indicates that the function returns an allocated resource.
- Return value constraint on error: specifies a return value constraint in case of allocation fail-ure failure if a resource allocator returns an integral value. Enter the condition in the following format: <comparison operator><integer value>. For example, if the function returns non-zero value on failure, enter "!=0" (without quotes) into the field. If return code on error is -1, type "==-1" there. In addition to "!=" and "==", you can use the following operators for specifying error conditions: ">", ">=", "<", and "<=".
...
Please, contact Parasoft Support for more information on how to use this functionality.
| Scroll Pagebreak |
|---|