Main Content

Managing Orange Checks in Polyspace Code Prover

Polyspace® checks every operation in your code for certain run-time errors. Therefore, you can have several orange checks in your verification results. To avoid spending unreasonable time on an orange check review, you must develop an efficient review process.

Depending on your stage of software development and quality goals, you can choose to:

Software Development Stage

Development StageSituationReview Process
Initial stage or unit development stage

In initial stages of development, you can have partially developed code or want to verify each source file independently. In that case, it is possible that:

  • You have not defined all your functions and class methods.

  • You do not have a main function

Because of insufficient information in the code, Polyspace makes assumptions that result in many orange checks. For instance, if you use the default configuration, Polyspace assumes full range for inputs of functions that are not called in the code.

In the initial stages of development, review all red checks. For orange checks, depending on your requirements, do one of the following:

  • You want your partially developed code to be free of errors independent of the remaining code. For instance, you want your functions to not cause run-time errors for any input.

    If so, review orange checks at this stage.

  • You might want your partially developed code to be free of errors only in the context of the remaining code.

    If so, do one of the following:

    • Ignore orange checks at this stage.

    • Provide the context and then review orange checks. For instance, you can provide stubs for undefined functions to emulate them more accurately.

      For more information, see Provide Context for Verification.

Later stage or integration stage

In later stages of development, you have provided all your source files. However, it is possible that your code does not contain all information required for verification. For example, you have variables whose values are known only at run time.

Depending on the time you want to spend, do one of the following:

  • Review red checks only.

  • Review red and critical orange checks.

Final stage

  • You have provided all your source files.

  • You have emulated run-time environment accurately through the verification options.

Depending on the time you want to spend, do one of the following:

  • Review red checks and critical orange checks.

  • Review red checks and all orange checks.

For each orange check:

  • If the check indicates a run-time error, fix the cause of the error.

  • If the check indicates a Polyspace approximation, enter a comment in your results or source code.

As part of your final release process, you can have one of these criteria:

  • All red and critical orange checks must be reviewed and justified.

  • All red and orange checks must be reviewed and justified.

To justify a check, assign the Status of No action planned or Justified to the check.

Quality Goals

For critical applications, you must review all red and orange checks.

  • If an orange check indicates a run-time error, fix the cause of the error.

  • If an orange check indicates a Polyspace approximation, enter a comment in your results or source code.

As part of your final release process, review and justify all red and orange checks. To justify a check, assign the Status of No action planned or Justified to the check.

For noncritical applications, you can choose whether or not to review the noncritical orange checks.

Related Examples

More About