Coverity Wizard is a component of Coverity® Analysis
Copyright © 2020 Synopsys, Inc. All rights reserved worldwide.
You can get started with Coverity Analysis, for any Coverity supported language, by using Coverity Wizard, a GUI-based application.
This guide covers tasks for setting up and running static quality, security, and test analyses in a centralized (server-based) build system.
The audience for this guide is administrators (including build engineers
and tools specialists) and power users who set up and run the Coverity analyses
in an integrated build environment. For details, see
Coverity Analysis Roles and Responsibilities
in the
Coverity Analysis 2020.12 User and Administrator Guide.
![]() | |
It is possible to run analyses from the command-line interface:
|
Coverity Wizard is a utility that allows you to complete the following Coverity Analysis tasks using an intuitive graphical user interface:
Configure Coverity tools to work with your compiler.
Build your source code under Coverity build capture.
Analyze your source code to find potential quality issues, security issues, and/or test issues.
Monitor your testing process to ensure its adherence to pre-defined test policy specifications.
Commit the analysis results to the Coverity Connect server which displays the issues and allows you to manage the issues through a web-based interface.
Coverity Wizard is installed as part of Coverity® Analysis. Refer to the
Coverity 2020.12 Installation and Deployment Guide
for a
complete list of hardware and software required.
The tutorial uses the default values for each screen, and a simple code example with
some issues to show you how to run an analysis on your own code. Each option in
Coverity Wizard has a help button () that you can click to get additional information on
its functionality and configuration.
Each screen of Coverity Wizard leads you through required configuration steps, providing both basic and more advanced options. You can complete each section in order, or you can go back to a previous screen to make changes at any stage of the workflow. The GUI interface has a left-hand navigation pane that provides an indicator for the active screen. The lower right corner provides buttons that link back to the previous screen, or forward to the next screen.
Indicators provide a visual context of your progress.
Table 2.1. Indicator Icons
Icon | Description |
---|---|
![]() | Indicates a completed phase of the workflow. |
![]() | Indicates that there is an error, or that the step is incomplete. |
These tutorials run through two examples using Coverity Wizard to set up configuration information.
The first scenario uses Coverity Wizard to configure Coverity Analysis
The second scenario illustrates a Test Advisor - Development Edition configuration.
The standard workflow for Coverity Wizard can be seen in Figure 3.1, “Standard workflow”. The red sections denote steps specific to Test Advisor configuration.
The following sections explain how to get started with Coverity Wizard and how to configure Coverity Analysis projects.
The Introduction screen is the first of six screens displayed by Coverity Wizard. To launch Coverity Wizard do one of the following:
On the Windows platform, a shortcut is placed on the desktop if you
choose, or you can run the cov-wizard
command from
the <install_dir>
/bin
directory, or have it in your PATH.
On Linux run the cov-wizard
command from the
<install_dir>
/bin
directory, or have it in your PATH.
On the Introduction screen, you must choose which products you want to configure
(Coverity Analysis, Test Advisor - Development Edition) and select a project name. Click to select
Quality and, optionally, Security;
these options indicate the types of analysis you want done. The tutorial project
name is myproject
, however you can customize this name.
Coverity Wizard provides the ability to configure a command line build and/or buildless capture, and Coverity Wizard will display the results. On Windows you can also have your Integrated Development Environment (IDE) perform the build; see Section 3.1.2.2, “IDE shortcut build”.
Configure the following fields, then click
:Select this check-box if your project contains any code that requires compilation. This will run a build capture that will compile and emit relevant files for analysis.
Compiler configuration options are described in Figure 3.4, “Automatically configure compilers”.
Select this check-box if your project contains any scripts or interpreted code. This will run buildless capture, which will emit relevant files for analysis.
For projects with compiled code, the Clean and Build commands will be run from this directory.
This button allows you to set additional cov-build
options, or configure other advanced settings that relate to the build
capture process. Use the help icon () associated with each option for
details.
Specifies the directory where all Coverity build and buildless capture information will be stored. This should be on fast local storage to ensure the analysis is as fast as possible.
It is recommended that you select the Command line build option, and specify the Clean and Build command for any compiled code in your project.
You can also choose to have your IDE complete the build capture step. See Section 3.1.2.2, “IDE shortcut build” for more information.
This button allows you to configure the compilers you would like to use.
It is recommended that you select the Scripts or Interpreted Code option to enable the buildless capture feature.
This button allows you to specify files or directories you would like to include or exclude from the buildless capture.
If your project uses any of the compilers listed below, you will only need to click the
button when prompted to automatically configure the most common compilers.GNU C/C++ compiler (gcc)
Sun/Oracle compiler (javac)
Clang compiler (clangcc)
Microsoft Visual C/C++ compiler (cl)
Microsoft Visual C# Compiler (csc)
Microsoft Visual Basic Compiler (vbc)
![]() | |
If your system uses .NET to compile Visual C# or Visual Basic,
The Microsoft Visual C/C++ and Microsoft C# compilers are supported on Windows only. On macOS, Coverity supports only the Unity Roslyn compiler. |
If you need to configure another compiler, say for example, the Wind River Diab compiler, follow these steps:
Click the
button.Choose Windriver Diab C Compiler (CIT) from the Compiler type dropdown menu.
Change the configuration name to diab-1. You can name it what you want to.
Enter the compiler's command line name. For the Wind River Diab C
compiler, it is dcc
.
![]() | |
For a compiler like the Wind River Diab C compiler that has both C and C++ variants, just enter the C compiler's name, and the C++ compiler will be configured automatically. |
Click
to add it to the list of configured compilers.The IDE option allows you to specify a Windows shortcut to your Integrated Development Environment (IDE) to perform the build.
To configure the build settings for use with the Coverity Wizard IDE feature, do the following:
Select the
button.Set your working directory.
![]() | |
The working directory is where the build commands are run.
For some IDEs, for example, Visual Studio, it does not
matter what directory you choose to run the IDE from. You
can set the working directory to
|
Use one of the options below to activate the IDE option:
Enter the filename of the link (.lnk) to your IDE or executable (.exe) to your IDE
Use the Browse button to find and choose it.
Drag and drop the Windows shortcut from your desktop to the Coverity Wizard interface.
Click the
button. Your IDE will open if successful. Close the IDE.Click the
button.When your IDE opens, use it to perform a clean and a full build of your code. A pop-up window will remain open reminding you to close the IDE after you perform the clean and full build.
Close your IDE.
Figure 3.6, “Analysis Settings Details” shows the analysis settings screen which lets you set various analysis options prior to running the analysis.
To set the analysis do the following:
Click on the
button.The results are displayed in the Analysis results summary pane. The Analysis results summary pane displays the date and the issues found.
![]() | |
This will perform the analysis with the default analysis settings enabled. To create a custom analysis, click on the button to access various analysis options prior to running the analysis. Click on the help icons for information on each of the options. |
Click the
button. Expand the → button tree node to view defect counts broken down by checker.After analyzing your code, you commit the analysis results to Coverity Connect. This tutorial assumes that you have access to an installed and configured instance of Coverity Connect. You must also have valid user credentials in the form of an authentication key file to connect to Coverity Connect, and the user must have a role with appropriate permissions to commit and view the issues (such as the admin role). If you do not have an authentication key file, you can generate one using your username and password. For installation instructions, see the Coverity 2020.12 Installation and Deployment Guide. For more information about user roles, see the Coverity Platform 2020.12 User and Administrator Guide..
To commit the analysis results, do the following:
Enter the following information in the Commit Defects panel:
Coverity Connect URL: The fully qualified URL for your Coverity Connect server.
This should include protocol, host name, and port number; for example, https://connect.synopsys.com:8080
.
If you are connecting to a Coverity Connect server over SSL, using a certificate signed by a recognized CA, the host name needs to match the name of the host on the certificate. This is not necessary when you use an unsecured connection, or when you use a self-signed certificate from Coverity Connect.
Use extra CA certificates: You can also turn on the check box for Use extra CA certificates and use the controls to point to a directory that contains additional CA certificates for communicating with Coverity Connect. For additional details, see "Using SSL with Coverity Analysis" in the Coverity Platform 2020.12 User and Administrator Guide.
For the Authentication Key File, click Browse to select an existing file.
If you do not have an authentication key file, click Generate a new key to create one. See Generating a new Authentication Key File
Click
.The Streams to commit to panel allows you to either select an existing stream name from the drop down menu or allows you to create a new stream name. If you choose , then a new project and stream will be automatically created with the same name in Coverity Connect.
![]() | |
Coverity Wizard requires streams to have a language set to 'ANY', otherwise they will not appear in the streams drop-down list. |
For purposes of this tutorial, a new stream named
myprojectxx-cpp
is created, but you can use any
name.
Click on the Name input field. By default, this stream will be available for use with Coverity Desktop Analysis tools. To disable this, please deselect the Enable Desktop Analysis checkbox.
button and enter the name of your choice in theClick
to finish.Click on the
button to commit your code to the Coverity Connect.![]() | |
If your
Coverity Analysis
Trust Store |
When you select the Commit Defects button the analysis results are sent to the Coverity Connect server. A link, as shown in Figure 3.8, “Viewing Results Screen ” takes you to the Coverity Connect application where you can view, manage, and triage the defects. Refer to Coverity Platform 2020.12 User and Administrator Guide for detailed information.
You can log into the Coverity Connect application using the same user name and password that you used to commit the defects.
After you log in, you will see the Coverity Connect application as shown in Figure 3.9, “View Defects”
The following sections provide you with the information necessary to configure Coverity Wizard for Test Advisor - Development Edition projects.
![]() | |
Test Advisor - Development Edition is not supported on Mac OS platforms. |
The Introduction screen is the first of six screens of Coverity Wizard. To launch Coverity Wizard do one of the following:
On the Windows platform, a shortcut is placed on the desktop if you
choose, or you can run the cov-wizard
command from
the <install_dir>
/bin
directory, or have it in your PATH.
On Linux run the cov-wizard
command from the
<install_dir>
/bin
directory, or have it in your PATH.
On this screen, you must choose which products you want to configure (Test Advisor -
Development Edition in this example) and select a project name. The tutorial project
name is myTAproject
, however you can customize this
name.
After you've selected which products you want to use, you can click the
button for a brief description of the Coverity Wizard configuration process.Coverity Wizard provides the ability to configure a command line build and/or buildless capture, and Coverity Wizard will display the results. On Windows you can also have your Integrated Development Environment (IDE) perform the build; see Section 3.2.2.2, “IDE shortcut build”.
Configure the following fields, then click
:Select this check-box if your project contains any code that requires compilation. This will run a build capture, which will compile and emit relevant files for analysis.
Select this check-box if your project contains any scripts or interpreted code. This will run a buildless capture, which will emit relevant files for analysis.
For projects with compiled code, the Clean and Build commands will be run from this directory.
This button allows you to set additional cov-build
options, or configure other advanced settings that relate to the build
capture process. Use the help icon () associated with each option for
details.
Specifies the directory where all Coverity build and buildless capture information will be stored. This should be on fast local storage to ensure the analysis is as fast as possible.
It is recommended that you select the Command line build option, and specify the Clean and Build command for any compiled code in your project.
You can also choose to have your IDE complete the build capture step. See Section 3.2.2.2, “IDE shortcut build” for more information.
This button allows you to configure the compilers you would like to use.
It is recommended that you select the Scripts or Interpreted Code option to enable the buildless capture feature.
This button allows you to specify files or directories you would like to include or exclude from the buildless capture.
Specify whether to run tests as a part of the build command (default), or to execute a separate command to run the tests after the build.
If you choose to execute an additional command after the build, enter the command in the provided text field.
This button will open the Test Advisor - Development Edition settings dialog.
Complete the following steps to configure your Test Advisor options:
Choose your project's coverage instrumentation tool from the drop-down menus. This example uses the Cobertura coverage tool for Java.
If you're running Test Advisor on a Java or C# project, you can also
select which test separation configuration you want to use to
detect your test boundaries — junit or junit4 for Java;
MSTest, NUnit, or XUnit for C#; or you can use a custom test
boundary property file for either language. For additional
information on setting test boundaries for your Test Advisor projects,
see the
Test Advisor 2020.12 User and Administrator Guide
.
If you would like to include revision histories in your Test Advisor build, choose your project's SCM system from the drop-down menu. Including this information will allow you to create test policy files that take code age and modification dates into account. Some SCMs require additional configuration in the SCM
menu.![]() | |
TFS and ADS are only supported on Windows platforms. |
If your project uses any of the compilers listed below, then you will only need to click the
button when prompted to automatically configure the most common compilers.GNU C/C++ compiler (gcc)
Sun/Oracle compiler (javac)
Clang compiler (clangcc)
Microsoft Visual C/C++ compiler (cl)
Microsoft C# Compiler (csc)
![]() | |
The Microsoft Visual C/C++ and Microsoft C# compilers are supported on Windows only. |
If you need to configure another compiler, say for example, the Wind River Diab compiler, then follow these steps:
Click the
button.Choose Windriver Diab C Compiler (CIT) from the Compiler type dropdown menu.
Change the configuration name to diab-1. You can name it what you want to.
Enter the compiler's command line name. For the Wind River Diab C
compiler, it is dcc
.
![]() | |
For a compiler like the Wind River Diab C compiler that has both C and C++ variants, just enter the C compiler's name, and the C++ compiler will be configured automatically. |
Click
to add it to the list of configured compilers.The IDE option allows you to specify a Windows shortcut to your Integrated Development Environment (IDE) to perform the build.
To configure the build settings for use with the Coverity Wizard IDE feature, do the following:
Select the
button.Set your working directory.
![]() | |
The working directory is where the build commands are run.
For some IDEs, for example, Visual Studio, it does not
matter what directory you choose to run the IDE from. You
can set the working directory to
|
Use one of the options below to activate the IDE option:
Enter the filename of the link (.lnk) to your IDE or executable (.exe) to your IDE
Use the Browse button to find and choose it.
Drag and drop the Windows shortcut from your desktop to the Coverity Wizard interface.
Click the
button. Your IDE will open if successful. Close the IDE.Under the Test Advisor - Development Edition settings pane, choose whether to run tests as a part of the build command (default), or to execute a separate command to run the tests after the build.
If you choose to execute an additional command after the build, enter the command in the provided text field.
Click the
button to configure additional Test Advisor options:Choose your project's coverage instrumentation tool from the drop-down menus. This example uses the Cobertura coverage tool for Java.
If you're running Test Advisor on a Java or C# project, you can
also select which test separation configuration you want to
use to detect your test boundaries — junit or junit4
for Java; MSTest, NUnit, or XUnit for C#; or you can use a
custom test boundary property file for either language. For
additional information on setting test boundaries for your
Test Advisor projects, see the
Test Advisor 2020.12 User and Administrator Guide
.
If you would like to include revision histories in your Test Advisor build, choose your project's SCM system from the drop-down menu. Including this information will allow you to create test policy files that take code age and modification dates into account. Some SCMs require additional configuration in the SCM
menu.![]() | |
TFS and ADS are only supported on Windows platforms. |
Click the
button.When your IDE opens, use it to perform a clean and full build of your code, and run your tests. A pop-up window will remain open reminding you to close the IDE after you perform the clean and full build.
Close your IDE.
To run an analysis on your test policies, complete the following steps:
Use the
button to navigate to your test policy file.![]() | |
If you need to create a new test policy file, use the Guided Test Policy Creation Wizard, or start from one of several test policy templates. You can also debug and edit your test policy file directly within Coverity Wizard by clicking the button. This will open the Test Advisor Policy Editor, which has several tools and views to help you create more effective test policy files. See Chapter 4, Using the Test Advisor Policy Editor and Debugger for additional details. drop-down menu to select how you would like to create the file; you can either use the |
Click the
button to complete your test analysis.The results are displayed in the Analysis results summary pane. The Analysis results summary pane displays the date and the issues found.
![]() | |
This will perform the analysis with the default analysis settings enabled. If you would like to create a custom analysis, click on the button to access various analysis options prior to running the analysis. Click on the help icons for information on each of the options. |
Click the
button. Expand the → button tree node to view defect counts broken down by checker.In this phase of the workflow, you commit the analysis results to Coverity Connect. This tutorial assumes that you have access to an installed and configured instance of Coverity Connect. You must also have a valid user credential in the form of an authentication key file to connect to Coverity Connect, and you must have a role with appropriate permissions to commit and view the issues (such as the admin role). If you do not have an authentication key file, you can generate one using your username and password. For installation instructions, see the Coverity 2020.12 Installation and Deployment Guide. For more information about user roles, see the Coverity Platform 2020.12 User and Administrator Guide..
To commit the analysis results, do the following:
Enter the following information in the Coverity Connect settings panel:
Host Name of the machine where Coverity Connect is installed.
Select your connection type (Secured or Unsecured). A secured connection uses SSL to communicate with the Coverity Connect server, while an unsecured connection uses no encryption.
You can also select the Add CA
certificates option to point to a certificate or
certificate chain file (.pem
) for
communicating with Coverity Connect. See "Client-side SSL Certificate
Management" in the Coverity Platform 2020.12 User and Administrator Guide for additional details.
Enter the port number for the web interface of Coverity Connect. This number is chosen when Coverity Connect is installed. The default port number is 8080 for HTTP and 8443 for HTTPS when using secured connection.
Type admin in the Username field (or another username that is in Coverity Connect that has privileges to commit snapshots).
Enter the password for the entered user. (The password for the admin user is initially set when Coverity Connect is installed.)
Click on the
button.The Streams to commit to panel allows you to either select an existing stream name from the drop down menu or allows you to create a new stream name. If you choose , then a new project and stream will be automatically created with the same name in Coverity Connect.
For purposes of this tutorial, a new stream named
myprojectxx-cpp
is created, but you can use any
name.
Click on the Name input field. By default, this stream will be available for use with Coverity Desktop Analysis tools. To disable this, please deselect the Enable Desktop Analysis checkbox.
button and enter the name of your choice in theClick
to finish.Click on the
button to commit your code to the Coverity Connect.![]() | |
If your
Coverity Analysis
Trust Store |
When you select the Commit Defects button the analysis results are sent to the Coverity Connect server. A link, as shown in Figure 3.8, “Viewing Results Screen ” takes you to the Coverity Connect applicaton where you can view, manage, and triage the defects. Refer to Coverity Platform 2020.12 User and Administrator Guide for detailed information.
You can log into the Coverity Connect application using the same user name and password that you used to commit the defects.
After you log in, you will see the Coverity Connect application as shown in Figure 3.18, “View Defects”
This section provides an overview of the views and options in the Test Advisor policy editor, for use with JSON test policy files. You can access the Policy Editor and Debugger from the Analysis Settings screen in Coverity Wizard. This tool not only allows you to edit and debug your test policy files, but also test the results of the file on your codebase. This will give you the ability to more rapidly update your test policy files and test for your desired results.
You can either edit and debug an existing test policy file by browsing to its location and clicking the
button, or create a new policy file by clicking the button.This section assumes that you have a working knowledge of Coverity Test Advisor - Development Edition and Test Advisor policy
concepts. For more information on Test Advisor and policy files, see
Test Advisor 2020.12 User and Administrator Guide
.
Select
to create a new policy file. You will be shown a pop-up window in order to select a template test policy file to start from.The left pane, titled Select a template, lists each of the available template files, while the right pane displays a preview of the file with a short commented description of the test policy file at the top. Select the one that works best for your project and click OK.
Upon opening the editor, your test policy file is displayed in the main window.
You can use this window to examine your test policy file for errors, as well as make changes
and save your updates directly within Coverity Wizard. When editing the policy, press
Ctrl-Space
to see a list of context appropriate options for
quicker editing/formatting. This will auto-complete the line when only one option exists
for what you have already typed.
In addition to the full text of your policy file, the text editor features the tools listed in Table 4.1, “Test Advisor Policy Editor tools” to help you create and navigate your test policy file.
Table 4.1. Test Advisor Policy Editor tools
Name | Icon | Description |
---|---|---|
Format |
![]() | Reformats the test policy file into clean text-blocks based on bracketed groups. |
Find/Replace... |
![]() | Search and replace tool for text occurrences in your test policy file. |
Collapse |
![]() | Collapse a block of text to display only the top-level element. Click again to expand the section. |
Text error |
![]() | Highlights a text error on a specific line. Hover over the icon for a short description of the issue. |
Warning |
![]() | Highlights a potential text error on a specific line. Hover over the icon for a short description of the issue. |
The outline view, in the upper-right pane of the editor, displays a basic outline of your test policy file. In this view, you can explore existing sections in the file, and add new elements as needed.
Upon opening the editor, the outline displays each of the top-level elements in
the test policy file (type, format_version, recent_date_cutoff,
old_date_cutoff, rules
, and define_filters
). Any
element that contains sub-sections can be expanded and collapsed by clicking its
corresponding node button ().
The outline view also provides the tools in Table 4.2, “Test Advisor Policy Editor tools” to help you navigate the file outline.
Table 4.2. Test Advisor Policy Editor tools
Name | Icon | Description |
---|---|---|
Link with Editor |
![]() | Links the outline to the file contents in the text editor view. When enabled, clicking on an element in the outline will display and highlight that element in the text editor view. Conversely, the selected item in the outline will also be updated as you click through the text editor. |
Sort |
![]() | Sorts all top-level elements alphabetically. All sub-elements are also sorted within their respective contexts. |
In addition to navigation, the outline view also helps you modify your test policy file. Right-click on any of the elements to bring up a menu of options relative to the specific item.
The options available from this menu, depending on the type of element, are:
This option allows you to add a new filter under the rules section. This will open a sub-menu of filter types to choose from. Click one of the choices to have it added to your policy file in the appropriate location. You can then modify the inserted filter to meet your needs.
This option will delete the element and any child elements below it.
This option will open the product documentation for the selected node in your web browser.
This option will evaluate the selected rule or named filter against your current project.
The Policy Debug view evaluates your entire test policy file against your current project, then displays the results in the project's file tree. To run the evaluation, choose your project's language and click the button.
The file tree lists all of the files and directories in your project, and displays the number of violations and policy coverage percentage in each. You can filter the displayed directories using the Included, Excluded, or With violation radio buttons. Select an individual file to display the text in the view pane.
If your project has a large number of translation units (TUs), the analysis can take a long time to complete. To compensate for this, you can apply a TU filter to limit the number of translation units being analyzed by the process and reduce the time to start the debugger.
If your project contains over 100 translation units, you will be prompted to add a TU filter as soon as you open the policy editor. Otherwise, to open the Filter Translation Units dialog, click on the button. See Figure 4.1, “Filter Translation Units” for an example of this view.
You can use the file tree to select the TUs you would like to include in the analysis, or enter a Filter TU Pattern, as defined in the Test Advisor 2020.12 User and Administrator Guide.
![]() | |
Because the TU filter limits the amount of files that will be analyzed, some defects may not be found. Therefore, expanding the set of included translation units will generally yield more accurate results. If you require a complete set of defects from your analysis, do not include a TU filter. This will require more time to complete the analysis (perhaps overnight). Once completed, further evaluations will complete much quicker as long as you don't exit from the editor/debugger. For additional information on effectively implementing Translation Unit filters, see Section 4.5, “Translation Unit Filter reference”. |
When running an analysis with a Translation Unit Filter, Test Advisor results may be different than the results of analysis without a Translation Unit Filter. Results of filters in the Test Advisor policy may differ due to information which is omitted based on the specific Translation Unit Filter used. In particular, the following filters are affected:
UnconditionalTerminateCallASTNodeFilter
ImpactedDateLineFilter
AffectedDateLineFilter
Because the results of the policy analysis may change when a Translation Unit Filter is used, a complete run of analysis without a Translation Unit Filter is necessary to guarantee a correct set of defects from Test Advisor. However, simply expanding the set of included Translation Units may yield more accurate results in certain cases when the above-mentioned filters are used.
This section illustrates the typical end-to-end workflow for creating a new Test Advisor Policy file using the wizard. You can access the Policy Creation Wizard from the Analysis Settings screen, by selecting from the drop-down menu.
The wizard consists of a single dialog, with collapsible sections for introductory information, code age thresholds, violation criteria, and filters. Upon completing the configuration of all of the sections, click . From there you can further edit your policy file, or click to use your policy file with Coverity Wizard for Test Advisor - Development Edition.
Be sure to read and understand the information in this section before configuring the options in the subsequent sections.
A Test Advisor policy file expresses the testing related rules you wish to enforce in your project. The policy file defines the conditions under which violations will be reported for insufficient test coverage in your code.
This wizard will guide you through the process of creating and customizing a policy file for a range of standard scenarios. The policy file code will be automatically generated for you.
In the interest of simplicity, this wizard will limit you to creating one definition of a violation type (that is, a single rule) per policy file. Test Advisor policy files can contain any number of rules, however, and you can copy rules generated via this wizard into other policy files should you wish to do so.
The Code Age Thresholds section helps you set cutoff dates to determine whether the code being analyzed is "old," "medium-aged," or "new." This helps you identify which test violations are most important, as newer code is more likely to contain bugs, and thus should not go untested.
Use the Old date cutoff and Recent date cutoff fields to specify the threshold dates you wish to use for each. Typically, the date of your most recent release will serve as the Recent Date Cutoff, and the date of the previous release will be the Old Date Cutoff.
The Violation Criteria section helps you specify what type of testing violation will be captured by the Test Advisor policy. Complete the following configuration steps:
Create a name for the violation in the Violation name field.
This name will be shown as the checker name for all instances of the violation. Be sure
that it is descriptive enough to aid users in understanding the nature of the violation
(for example, FUNCTION_INSUFFICIENTLY_TESTED
).
Select if you want to see test violations on a per-function or per-file basis. If you select Functions, the filter criteria in this rule will test each function to see if it violates the policy. When Files is selected, the filter criteria will test each file to see if it violates the policy.
Any function of file that violates the rule will then result in a test violation.
Specify what percentage of lines must be covered under the rule. This percentage applies to the lines of code that remain after any specified filters have been applied.
If test coverage is less than this percentage of any relevant file or function, a violation will be reported.
The conditions of your violation criteria can be further refined by adding one or more filters. Several of the most commonly used filters are configurable in the Filters section.
You can include any of the listed filters by checking the box next to its name. Each filter
has a help button () which explains its impact.
This section provides workarounds and procedures for solving common problems that might occur when you run Coverity Wizard.
On Windows and Linux systems, pressing the Tab key will allow you to cycle through all of the controls on the page. However, in Mac OS X, the default operating system setting is to allow the focus to only land on text fields and lists, bypassing buttons and other controls. To change this setting to allow keyboard navigation and activation of buttons and combo boxes:
Open the Apple menu and go to System Preferences -> Keyboard
Go to the Keyboard Shortcuts tab.
Under Full Keyboard Access, change the setting from Text boxes and lists only to All controls.
If you are having trouble with the IDE shortcut feature using Visual Studio please refer to the following:
If Visual Studio requires elevated permission (i.e. Run as Administrator is selected under Privilege Level in the Compatibility tab of the Visual Studio shortcut properties window), then you must run Coverity Wizard as Administrator level privileges.
Enabling Instrument mode in the Advanced tab is discouraged when using Visual Studio. When trying Instrument mode, some path settings may be required, as described in the Coverity Desktop 2020.12 for Microsoft Visual Studio: User Guide.
A tree-shaped data structure that represents the structure of concrete input syntax (from source code).
In Coverity Connect, a customizable attribute used to triage a CID. Default values are Undecided, Fix Required, Fix Submitted, Modeling Required, and Ignore. Alternative custom values are possible.
The number of execution paths in a function, with loops counted one time at most. The following assumptions are also made:
continue
breaks out of a loop.
while
and for
loops are executed exactly
0 or 1 time.
do…while
loops are executed exactly once.
goto
statements which go to an earlier source
location are treated as an exit.
Acyclic (Statement-only) Path Count adds the following assumptions:
Paths within expressions are not counted.
Multiple case labels at the same statement are counted as a single case.
In Coverity Connect, streams that are associated with the same triage store always share the same triage data and history. For example, if Stream A and Stream B are associated with Triage Store 1, and both streams contain CID 123, the streams will share the triage values (such as a shared Bug classification or a Fix Required action) for that CID, regardless of whether the streams belong to the same project.
Advanced triage allows you to select one or more triage stores to update when triaging a CID in a Coverity Connect project. Triage store selection is possible only if the following conditions are true:
Some streams in the project are associated with one triage store (for example, TS1), and other streams in the project are associated with another triage store (for example, TS2). In this case, some streams that are associated with TS1 must contain the CID that you are triaging, and some streams that are associated with TS2 must contain that CID.
You have permission to triage issues in more than one of these triage stores.
In some cases, advanced triage can result in CIDs with issue attributes that are in the Various state in Coverity Connect.
See also, triage.
A marker in the source code. An analysis annotation is not executable, but modifies the behavior of Coverity Analysis in some way.
Analysis annotations can suppress false positives, indicate sensitive data, and enhance function models.
Each language has its own analysis annotation syntax and set of capabilities. These are not the same as the syntax or capabilities available to the other languages that support annotations.
For C/C++, an analysis annotation is a comment with special formatting. See code-line annotation and function annotation.
For C# and Visual Basic, an analysis annotation uses the native C# attribute syntax.
For Java, an analysis annotation uses the native Java annotation syntax.
Other languages do not support annotations.
See analysis annotation.
A graph in which functions are nodes, and the edges are the calls between the functions.
See issue category.
A program that traverses paths in your source code to find specific issues in it. Examples of checkers include RACE_CONDITION, RESOURCE_LEAK, and INFINITE_LOOP. For details about checkers, see Coverity 2020.12 Checker Reference.
See issue category.
A measure of change in defect reporting between two Coverity Analysis releases that are separated by one minor release, for example, 6.5.0 and 6.6.0.
A category that is assigned to a software issue in the database. Built-in classification values are Unclassified, Pending, False Positive, Intentional, and Bug. For Test Advisor issues, classifications include Untested, No Test Needed, and Tested Elsewhere. Issues that are classified as Unclassified, Pending, and Bug are regarded as software issues for the purpose of defect density calculations.
For C/C++, an analysis annotation that applies to a particular line of code. When it encounters a code-line annotation, the analysis engine skips the defect report that the following line of code would otherwise trigger.
By default, an ignored defect is classified as
Intentional
.
See "Models and Annotations in C/C++" in the Coverity Checker Reference.
See also function annotation.
A set of related source files.
The amount of code that is tested as a percentage of the total amount of code. Code coverage is measured different ways: line coverage, path coverage, statement coverage, decision coverage, condition coverage, and others.
A named grouping of source code files. Components allow developers to view only issues in the source files for which they are responsible, for example. In Coverity Connect, these files are specified by a Posix regular expression. See also, component map.
Describes how to map source code files, and the issues contained in the source files, into components.
A graph in which blocks of code without any jumps or jump targets are nodes, and the directed edges are the jumps in the control flow between the blocks. The entry block is where control enters the graph, and the exit block is where the control flow leaves.
An identification number assigned to a software issue. A snapshot contains issue instances (or occurrences), which take place on a specific code path in a specific version of a file. Issue instances, both within a snapshot and across snapshots (even in different streams), are grouped together according to similarity, with the intent that two issues are "similar" if the same source code change would fix them both. These groups of similar issues are given a numeric identifier, the CID. Coverity Connect associates triage data, such as classification, action, and severity, with the CID (rather than with an individual issue).
A community-developed list of software weaknesses, each of which is assigned a
number (for example, see CWE-476 at http://cwe.mitre.org/data/definitions/476.html
).
Coverity associates many categories of defects (such as "Null pointer
dereferences") with a CWE number.
A Web application that allows developers and managers to identify, manage, and fix issues found by Coverity analysis and third-party tools.
The directory that contains the Coverity Connect database. After analysis, the
cov-commit-defects
command stores defects in this
directory. You can use Coverity Connect to view the defects in this directory. See also
intermediate directory.
Code that cannot possibly be executed regardless of what input values are provided to the program.
See issue.
A characteristic of a function or algorithm that, when given the same input, will always give the same output.
Issue marked by developers as Intentional or False Positive in the Triage pane. When such issues are no longer present in the latest snapshot of the code base, they are identified as absent dismissed.
A combination of the language that is being analyzed and the type of analysis, either static or dynamic.
Analysis of software code by executing the compiled program. See also static analysis.
A JVM agent for Dynamic Analysis that instruments your program to gather runtime evidence of defects.
A sequential collection of snapshots, which each contain all of the issues that Dynamic Analysis reports during a single invocation of the Dynamic Analysis broker.
In Coverity Connect, a software issue is composed of one or more events found by the analysis. Events are useful in illuminating the context of the issue. See also issue.
A defect in the source code that is not found by Coverity Analysis.
A technique to ensure that defects are only detected on feasible paths. For
example, if a particular path through a method ensures that a given condition is
known to be true, then the else
branch of an if
statement which tests that condition cannot be reached on that path. Any defects
found in the else
branch would be impossible because they are “on a
false path”. Such defects are suppressed by a false path pruner.
A potential defect that is identified by Coverity Analysis, but that you decide is not a defect. In Coverity Connect, you can dismiss such issues as false positives. In C or C++ source, you might also use code-line annotations to identify such issues as intentional during the source code analysis phase, prior to sending analysis results to Coverity Connect.
Issue from the previous snapshot that is not in the latest snapshot.
The Extend SDK engine notices that the second and subsequent paths through the loop are not significantly different from the first iteration, and stops analyzing the loop. This condition is called a fixpoint of the loop.
A checker that is stateless. The abstract syntax trees are not visited in any particular order.
For C/C++, an analysis annotation that applies to the definition of a particular function. The annotation either suppresses or enhances the effect of that function's model. See "Models and Annotations in C/C++" in the Coverity Checker Reference.
See also code-line annotation.
A model of a function that is not in the code base that enhances the intermediate representation of the code base that Coverity Analysis uses to more accurately analyze defects.
Term that is intended to indicate the likely urgency of fixing the issue, primarily considering its consequences for software quality and security, but also taking into account the accuracy of the checker. Impact is necessarily probabilistic and subjective, so one should not rely exclusively on it for prioritization.
Issue that has been triaged or fixed by developers.
A directory that is specified with the --dir
option to many
commands. The main function of this directory is to write build and analysis
results before they are committed to the Coverity Connect database as a snapshot. Other more specialized commands that
support the --dir
option also write data to or read data from
this directory.
The intermediate representation of the build is stored in
<intermediate_directory>/emit
directory, while the analysis results are
stored in <intermediate_directory>/output
. This directory can contain
builds and analysis results for multiple languages.
See also data directory.
The output of the Coverity compiler, which Coverity Analysis uses to run its analysis and check for defects. The intermediate representation of the code is in the intermediate directory.
An analysis for defects based on the interaction between functions. Coverity Analysis uses call graphs to perform this type of analysis. See also intraprocedural analysis.
An analysis for defects within a single procedure or function, as opposed to interprocedural analysis.
Coverity Connect displays three types of software issues: quality defects, potential security vulnerabilities, and test policy violations. Some checkers find both quality defects and potential security vulnerabilities, while others focus primarily on one type of issue or another. The Quality, Security, and Test Advisor dashboards in Coverity Connect provide high-level metrics on each type of issue.
Note that this glossary includes additional entries for the various types of issues, for example, an inspected issue, issue category, and so on.
A string used to describe the nature of a software issue; sometimes called a "checker category" or simply a "category." The issue pertains to a subcategory of software issue that a checker can report within the context of a given domain.
Examples:
Memory - corruptions
Incorrect expression
Integer overflow Insecure data handling
Impact tables in the Coverity 2020.12 Checker Reference list issues found by checkers according to their category and other associated checker properties.
For Coverity Analysis for C/C++, a path in a function that aborts program execution. See
<install_dir_sa>/library/generic/common/killpath.c
for
the functions that are modeled in the system.
For Coverity Analysis for Java, and similarly for C# and Visual Basic, a modeling primitive
used to indicate that execution terminates at this point, which prevents the
analysis from continuing down this execution path. It can be used to model a
native method that kills the process, like System.exit
, or to
specifically identify an execution path as invalid.
A string that indicates whether software issues found by a given checker pertain to SECURITY (for security issues), QUALITY (for quality issues), TEST (for issues with developer tests, which are found by Test Advisor), or QUALITY/SECURITY. Some checkers can report quality and security issues. The Coverity Connect UI can use this property to filter and display CIDs.
A CID's state in the latest snapshot merged with its state from previous snapshots starting with the snapshot in which its state was 'New'.
Interprocedural analysis on a subset of the code base with Coverity Desktop plugins, in contrast to one with Coverity Analysis, which usually takes place on a remote server.
A string serving as a generic event message that explains why the checker reported a defect. The message is based on a subcategory of software issues that the checker can detect. Such strings appear in the Coverity Connect triage pane for a given CID.
Examples:
May result in a security violation.
There may be a null pointer exception, or else the comparison
against null is unnecessary.
A string that provides an extended description of a software issue (compare with type). The long description appears in the Coverity Connect triage pane for a given CID. In Coverity Connect, this description is followed by a link to a corresponding CWE, if available.
Examples:
The called function is unsafe for security related code.
All paths that lead to this null pointer comparison already
dereference the pointer earlier (CWE-476).
In Coverity Analysis of the code for a compiled language—such as C, C++, C#, Java, or Visual Basic—a model represents a function in the application source. Models are used for interprocedural analysis.
Each model is created as each function is analyzed. The model is an abstraction of the function’s behavior at execution time; for example, a model can show which arguments the function dereferences, and whether the function returns a null value.
It is possible to write custom models for a code base. Custom models can help improve Coverity's ability to detect certain kinds of bugs. Custom models can also help reduce the incidence of false positives.
A modeling primitive is used when writing custom models. Each modeling primitive is a function stub: It does not specify any executable code, but when it is used in a custom model it instructs Coverity Analysis how to analyze (or refrain from analyzing) the function being modeled.
For example, the C/C++ checker CHECKED_RETURN is associated with the modeling primitive _coverity_always_check_return_()
.
This primitive tells CHECKED_RETURN to verify that the function being analyzed really does return a value.
Some modeling primitives are generic, but most are specific to a particular checker or group of checkers. The set of available modeling primitives varies from language to language.
Issues that are uninspected and unresolved.
The sum of security and non-security defects count.
The sum of non-security defects count.
The sum of security defects count.
User name of the user to whom an issue has been assigned in Coverity Connect. Coverity Connect identifies the owner of issues not yet assigned to a user as Unassigned.
The recursive visiting of children of a given node in order, and then the visit to the node itself. Left sides of assignments are evaluated after the assignment because the left side becomes the value of the entire assignment expression.
In the Java language, elemental data types such as strings and integers are known as primitive types. (In the C-language family, such types are typically known as basic types).
For the function stubs that can be used when constructing custom models, see modeling primitive.
In Coverity Connect, a specified set of related streams that provide a comprehensive view of issues in a code base.
Issues that have been fixed or marked by developers as Intentional or False Positive through the Coverity Connect Triage pane.
In Coverity releases 4.5.x or lower, a grouping of defects committed to the
Coverity Connect. Each time defects are inserted into the Coverity Connect using the
cov-commit-defects
command, a new run is created, and the
run ID is reported. See also snapshot
To clean or validate tainted data to ensure that the data is valid. Sanitizing tainted data is an important aspect of secure coding practices to eliminate system crashes, corruption, escalation of privileges, or denial of service. See also tainted data.
In Coverity Connect, a customizable property that can be assigned to CIDs. Default values are Unspecified, Major, Moderate, and Minor. Severities are generally used to specify how critical a defect is.
Coverity Analysis for C/C++: Any operation or function that must be protected from tainted
data. Examples are array subscripting, system(),
malloc()
.
Coverity Analysis for Java: Any operation or function that must be protected from tainted
data. Examples are array subscripting and the JDBC API
Connection.execute
.
A copy of the state of a code base at a certain point during development. Snapshots help to isolate defects that developers introduce during development.
Snapshots contain the results of an analysis. A snapshot includes both the issue information and the source code in which the issues were found. Coverity Connect allows you to delete a snapshot in case you committed faulty data, or if you committed data for testing purposes.
Determines the snapshots from which the CID are listed using the Show and the optional Compared To fields. The show and compare scope is only configurable in the Settings menu in Issues:By Snapshot views and the snapshot information pane in the Snapshots view.
An entry point of untrusted data. Examples include environment variables, command line arguments, incoming network data, and source code.
Analysis of software code without executing the compiled program. See also dynamic analysis.
Describes the state of an issue. Takes one of the following values:
New
, Triaged
,
Dismissed
, Absent Dismissed
, or
Fixed
.
A map from abstract syntax trees to integer values and a sequence of events. This map can be used to implement an abstract interpreter, used in flow-sensitive analysis.
A sequential collection of snapshots. Streams can thereby provide information about software issues over time and at a particular points in development process.
Any data that comes to a program as input from a user. The program does not have control over the values of the input, and so before using this data, the program must sanitize the data to eliminate system crashes, corruption, escalation of privileges, or denial of service. See also sanitize.
A translation unit is the smallest unit of code that can be compiled separately. What this unit is, depends primarily on the language: For example, a Java translation unit is a single source file, while a C or C++ translation unit is a source file plus all the other files (such as headers) that the source file includes.
When Coverity tools capture code to analyze, the resulting intermediate directory contains a collection of translation units. This collection includes source files along with other files and information that form the context of the compilation. For example, in Java this context includes bytecode files in the class path; in C or C++ this context includes both preprocessor definitions and platform information about the compiler.
The process of setting the states of an issue in a particular stream, or of issues that occur in multiple streams. These user-defined states reflect items such as how severe the issue is, if it is an expected result (false positive), the action that should be taken for the issue, to whom the issue is assigned, and so forth. These details provide tracking information for your product. Coverity Connect provides a mechanism for you to update this information for individual and multiple issues that exist across one or more streams.
See also advanced triage.
A repository for the current and historical triage values of CIDs. In Coverity Connect, each stream must be associated with a single triage store so that users can triage issues (instances of CIDs) found in the streams. Advanced triage allows you to select one or more triage stores to update when triaging a CID in a Coverity Connect project.
See also advanced triage.
A string that typically provides a short description of the root cause or potential effect of a software issue. The description pertains to a subcategory of software issues that the checker can find within the scope of a given domain. Such strings appear at the top of the Coverity Connect triage pane, next to the CID that is associated with the issue. Compare with long description.
Examples:
The called function is unsafe for security related code
Dereference before null check
Out-of-bounds access
Evaluation order violation
Impact tables in the Coverity 2020.12 Checker Reference list issues found by checkers according to their type and other associated checker properties.
An issue that is identical and present in multiple streams. Each instance of an identical, unified issue shares the same CID.
Issues that are as yet unclassified in Coverity Connect because they have not been triaged by developers.
Defects are marked by developers as Pending or Bug through the Coverity Connect Triage pane. Coverity Connect sometimes refers to these issues as Outstanding issues.
Coverity Connect uses the term Various in two cases:
When a checker is categorized as both a quality and a security checker. For example, USE_AFTER_FREE and UNINIT are listed as such in the Issue Kind column of the View pane. For details, see the Coverity 2020.12 Checker Reference.
When different instances of the same CID are triaged differently. Within the scope of a project, instances of a given CID that occur in separate streams can have different values for a given triage attribute if the streams are associated with different triage stores . For example, you might use advanced triage to classify a CID as a Bug in one triage store but retain the default Unclassified setting for the CID in another store. In such a case, the View pane of Coverity Connect identifies the project-wide classification of the CID as Various.
Note that if all streams share a single triage store, you will never encounter a CID in this triage state.
Saved searches for Coverity Connect data in a given project. Typically, these searches are filtered. Coverity Connect displays this output in data tables (located in the Coverity Connect View pane). The columns in these tables can include CIDs, files, snapshots, checker names, dates, and many other types of data.
The information contained in this document, and the Licensed Product provided by Synopsys,
are the proprietary and confidential information of Synopsys, Inc. and its affiliates and
licensors, and are supplied subject to, and may be used only by Synopsys customers in
accordance with the terms and conditions of a license agreement previously accepted by
Synopsys and that customer. Synopsys' current standard end user license terms and conditions
are contained in the cov_EULM
files located at
<install_dir>/doc/en/licenses/end_user_license
.
Portions of the product described in this documentation use third-party material. Notices,
terms and conditions, and copyrights regarding third party material may be found in the
<install_dir>/doc/en/licenses
directory.
Customer acknowledges that the use of Synopsys Licensed Products may be enabled by authorization keys supplied by Synopsys for a limited licensed period. At the end of this period, the authorization key will expire. You agree not to take any action to work around or override these license restrictions or use the Licensed Products beyond the licensed period. Any attempt to do so will be considered an infringement of intellectual property rights that may be subject to legal action.
If Synopsys has authorized you, either in this documentation or
pursuant to a separate mutually accepted license agreement, to
distribute Java source that contains Synopsys annotations, then your
distribution should include Synopsys'
analysis_install_dir/library/annotations.jar
to
ensure a clean compilation. This annotations.jar
file contains proprietary intellectual property owned by Synopsys.
Synopsys customers with a valid license to Synopsys' Licensed Products
are permitted to distribute this JAR file with source that has been
analyzed by Synopsys' Licensed Products consistent with the terms of
such valid license issued by Synopsys. Any authorized distribution must
include the following copyright notice: Copyright
© 2020 Synopsys, Inc. All rights reserved
worldwide.
U.S. GOVERNMENT RESTRICTED RIGHTS: The Software and associated documentation are provided with Restricted Rights. Use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software – Restricted Rights at 48 CFR 52.227-19, as applicable.
The Manufacturer is: Synopsys, Inc. 690 E. Middlefield Road, Mountain View, California 94043.
The Licensed Product known as Coverity is protected by multiple patents and patents pending, including U.S. Patent No. 7,340,726.
Coverity and the Coverity logo are trademarks or registered trademarks of Synopsys, Inc. in the U.S. and other countries. Synopsys' trademarks may be used publicly only with permission from Synopsys. Fair use of Synopsys' trademarks in advertising and promotion of Synopsys' Licensed Products requires proper acknowledgement.
Microsoft, Visual Studio, and Visual C# are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
Microsoft Research Detours Package, Version 3.0.
Copyright © Microsoft Corporation. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or affiliates. Other names may be trademarks of their respective owners.
"MISRA", "MISRA C" and the MISRA triangle logo are registered trademarks of MISRA Ltd, held on behalf of the MISRA Consortium. © MIRA Ltd, 1998 - 2013. All rights reserved. The name FindBugs and the FindBugs logo are trademarked by The University of Maryland.
Other names and brands may be claimed as the property of others.
This Licensed Product contains open source or community source software ("Open Source Software") provided under separate license terms (the
"Open Source License Terms"), as described in the
applicable license agreement under which this Licensed Product is licensed ("Agreement"). The applicable Open Source License Terms are
identified in a directory named licenses
provided with the delivery of
this Licensed Product. For all Open Source Software subject to the terms of an LGPL license,
Customer may contact Synopsys at software-integrity-support@synopsys.com
and Synopsys will comply with the terms of the
LGPL by delivering to Customer the applicable requested Open Source Software package, and
any modifications to such Open Source Software package, in source format, under the
applicable LGPL license. Any Open Source Software subject to the terms and conditions of the
GPLv3 license as its Open Source License Terms that is provided with this Licensed Product
is provided as a mere aggregation of GPL code with Synopsys' proprietary code, pursuant to
Section 5 of GPLv3. Such Open Source Software is a self-contained program separate and apart
from the Synopsys code that does not interact with the Synopsys proprietary code.
Accordingly, the GPL code and the Synopsys proprietary code that make up this Licensed
Product co-exist on the same media, but do not operate together. Customer may contact
Synopsys at software-integrity-support@synopsys.com
and Synopsys will comply with the terms of the GPL by delivering to
Customer the applicable requested Open Source Software package in source code format, in
accordance with the terms and conditions of the GPLv3 license. No Synopsys proprietary code
that Synopsys chooses to provide to Customer will be provided in source code form; it will
be provided in executable form only. Any Customer changes to the Licensed Product (including
the Open Source Software) will void all Synopsys obligations under the Agreement, including
but not limited to warranty, maintenance services and infringement indemnity
obligations.
The Cobertura package, licensed under the GPLv2, has been modified as of release 7.0.3.
The package is a self-contained program, separate and apart from Synopsys code that does not
interact with the Synopsys proprietary code. The Cobertura package and the Synopsys
proprietary code co-exist on the same media, but do not operate together. Customer may
contact Synopsys at software-integrity-support@synopsys.com
and Synopsys will comply with the terms of the GPL by
delivering to Customer the applicable requested open source package in source format, under
the GPLv2 license. Any Synopsys proprietary code that Synopsys chooses to provide to
Customer upon its request will be provided in object form only. Any changes to the Licensed
Product will void all Coverity obligations under the Agreement, including but not limited to
warranty, maintenance services and infringement indemnity obligations. If Customer does not
have the modified Cobertura package, Synopsys recommends to use the JaCoCo package
instead.
For information about using JaCoCo, see the description for cov-build
--java-coverage
in the Command Reference.
Copyright © All rights reserved. Developed by: LLVM Team, University of
Illinois at Urbana-Champaign (http://llvm.org/
). Permission
is hereby granted, free of charge, to any person obtaining a copy of LLVM/Clang
and associated documentation files ("Clang"), to deal with Clang without
restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of Clang, and to
permit persons to whom Clang is furnished to do so, subject to the following
conditions: Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimers. Redistributions
in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimers in the documentation and/or other
materials provided with the distribution. Neither the name of the University of
Illinois at Urbana-Champaign, nor the names of its contributors may be used to
endorse or promote products derived from Clang without specific prior written
permission.
CLANG IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH CLANG OR THE USE OR OTHER DEALINGS WITH CLANG.
Copyright © Rackspace, US Inc. All rights reserved. Licensed under the
Apache License, Version 2.0 (the "License"); you may not use these files except
in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright © 2020 Synopsys Inc. All rights reserved
worldwide. (www.synopsys.com
), with
Reserved Font Name fa-gear, fa-info-circle,
fa-question.
This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at
http://scripts.sil.org/OFL
.
Copyright © 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
The end-user documentation included with the redistribution, if any, must include the following acknowlegement: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally appear.
The names "The Jakarta Project", "Commons", and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
Products derived from this software may not be called "Apache" nor may "Apache" appear in their names without prior written permission of the Apache Group.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
http://www.apache.org/licenses/
Licensed under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at:
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Results of analysis from Coverity and Test Advisor represent the results of analysis as of the date and time that the analysis was conducted. The results represent an assessment of the errors, weaknesses and vulnerabilities that can be detected by the analysis, and do not state or infer that no other errors, weaknesses or vulnerabilities exist in the software analyzed. Synopsys does NOT guarantee that all errors, weakness or vulnerabilities will be discovered or detected or that such errors, weaknesses or vulnerabilities are are discoverable or detectable.
SYNOPSYS AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, CONDITIONS AND REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING THOSE RELATED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, ACCURACY OR COMPLETENESS OF RESULTS, CONFORMANCE WITH DESCRIPTION, AND NON-INFRINGEMENT. SYNOPSYS AND ITS SUPPLIERS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES, CONDITIONS AND REPRESENTATIONS ARISING OUT OF COURSE OF DEALING, USAGE OR TRADE.