Prepare Checkers Configuration for Polyspace Bug Finder Analysis

Before you incorporate Polyspace® as a tool in the software development process of your organization, first decide how you plan on using Polyspace to improve your code. Choose which source components to analyze, which issues to check for, and so on. You can then prepare analysis configuration files that reflect your choices.

A Bug Finder analysis configuration consists of two parts:

  • Build configuration including sources, compilers, and targets

  • Checkers configuration

This topic describes a workflow for creating your checkers configuration in a typical deployment scenario. You can adapt this workflow to the specific requirements of your project or organization.

Identify Checkers to Enable

Suppose that you want to establish certain coding standards across your organization. You might follow one of several approaches:

  • Adhere to an external coding standard — If Bug Finder supports the coding standard, you can select the standard and a predefined or custom set of rules from the standard.

    Polyspace Bug Finder™ supports external standards such as MISRA C™:2023, CWE, CERT C, and AUTOSAR C++14. For a list of supported coding standards, see Coding Standards.

    For supported standards, enable the standard in your configuration and start analysis. For more details about the workflow for checking coding rule violations, see Check for and Review Coding Standard Violations.

  • Develop your own custom coding standard — Create your own coding standard by including rules from existing standards and creating new rules when needed. See Create Your Own Coding Rules and Coding Standard.

    To locate checkers that you can use in your own coding standard, search by keywords in the documentation. Suppose you want to detect issues that can arise from use of variadic functions.

    1. Search for keywords such as variadic or va_arg and refine search results by product to Bug Finder.

    2. Identify all checkers related to variadic functions. Note down the checkers that you want to enable.

    3. Create code specification that contains the issues you want to detect related to variadic or va_arg and run a Bug Finder analysis after enabling the checkers you noted down.

    4. Refine the list of checkers for your coding standard by reviewing the result and identifying the checkers that best match your requirement.

    For details about this process, see See Find Polyspace Bug Finder Checkers That Map to Coding Rules in User-Defined Coding Standard.

    You can record each defect checker that you enabled or disabled for your process requirements. You can start from the spreadsheet of checkers in polyspaceroot\polyspace\resources\. In the Your Notes column, note down your rationale for enabling or disabling a checker.

  • Check for high impact issues that can cause runtime errors — Start from the Bug Finder defect checkers and identify a subset of checkers for which you want to have zero unjustified defects. One way to identify this subset can be the following:

    • First select defect checkers with high impact. These checkers can find issues that are likely to have serious consequences.

      See also Classification of Defects by Impact.

    • Run a first pass of Bug Finder analysis with high impact checkers and identify checkers that produce too much noise that you do not want to address immediately. You can disable these checkers for your initial deployment.

    See also Choose Specific Bug Finder Defect Checkers.

    You can follow a similar strategy with checkers for external coding standards. For instance, for MISRA C:2023, you can start from the mandatory or required guidelines and then choose to expand later.

At the end of this process, you have identified some checkers to enable in a Polyspace analysis. The next section describes how to create checkers configuration files that you can deploy to your developers.

Create Checkers Configuration Files

A Polyspace Bug Finder analysis configuration is a list of analysis options specified using command-line flags. You can store the entire configuration in one options file, for instance, a text file named allOptions.txt, and specify the file using -options-file like this:

polyspace-bug-finder -options-file allOptions.txt

Or like this:

polyspace-bug-finder-server -options-file allOptions.txt

For your convenience, you can split the configuration into parts:

  • Build configuration (sources, targets, and so on) — Save all options related to your build in an options file buildOptions.txt. You can create this file manually or automatically from your build command (makefile). For more information on how to create this file, see Configure Sources and Build Options in Project for Polyspace Analysis and Testing.

  • Defect checkers and external coding standard configuration — Specify checkers configuration in a checkers configuration file.

By splitting the build configuration and checkers configuration into separate options files, you can reuse the checkers configuration across projects while creating a build configuration individually for each project. Conversely, you can also use different checkers configurations while reusing the build configurations.

In the preceding section, you identified the checkers that you want to enable for your analyses. There are different ways you can collect the identified checkers into a single configuration file:

  • Create a checkers activation file (.xml) — Suppose you want to enable a set of external coding rules and Bug Finder defects using a single checkers activation file. You can create this XML using the Checkers Selection window. To open this window, at the command line, enter

    polyspace-checkers-selection
    In the Checkers selection window, select the defects and coding rules that you identified in the preceding section and save the selection as an XML file.

    If you prefer to use a text editor to create the XML file, start with example activation files located in the folder polyspaceroot\polyspace\examples\doc_cxx\checkers_activation_XML\.

    After creating the activation file, specify it as an input to Checkers activation file (-checkers-activation-file). For example, to use the checkers activation file checkers.xml, at the command line, enter:

    polyspace-bug-finder -options-file buildOptions.txt -checkers-activation-file checkers.xml
    For details about creating the XML file, see the examples in Checkers activation file (-checkers-activation-file).

  • Create a custom coding standard (.pschk) — Suppose you want to collect and organise the identified rules into an in-house coding standard. To create this custom coding standard, define the coding standard using Polyspace Query Language in a .pql file and then use the command polyspace-query-language to create a coding standard in a pschk file. Use the file in the Polyspace Platform user interface or at the command line. To specify a custom coding standard CustomCodingStandard.pschk, at the command line, enter

    polyspace-bug-finder -options-file buildOptions.txt -checkers-activation-file CustomCodingStandard.pschk
    For details about this workflow, see Create User-Defined Coding Standard by Using Polyspace Query Language.

Once you create the build option file and the checkers configuration file, you can run Polyspace using scripts that refer to these files. For instance:

  • In a Jenkins® build, you can specify the run command in a build script, along with other tools that you are running. After code submission, the Polyspace analysis can run on newly submitted code through the build scripts.

  • In Polyspace as You Code™ IDE extensions, you can use the checkers activation file (.XML) or the custom coding standard (.pschk) directly in your IDE.

Creating these options files by hand can be prone to errors. If you have a license of the desktop product, Polyspace Bug Finder, you can generate these files from the Polyspace user interface. See also Generate Launching Script for Polyspace Platform Project to Run Static Analysis from Command Line.

See Also

Topics