Annotate Code for Known or Acceptable Results (Not Recommended)

Note

Starting R2017b, Polyspace uses a simpler annotation format. See Annotate Code and Hide Known or Acceptable Results.

If Polyspace finds defects in your code that you cannot or will not fix, you can add annotations to your code. These annotations are code comments that indicate known or acceptable defects or coding rule violations. By using these annotations, you can:

Avoid reviewing defects or coding rule violations from previous analyses that you have laredy reviewed.
Preserve review comments and classifications.

Note

Source code annotations do not apply to code comments. You cannot annotate these rules:

MISRA C™:2004 Rules 2.2 and 2.3
MISRA C:2012 Rules 3.1 and 3.2
MISRA-C++ Rule 2-7-1
JSF++ Rules 127 and 133

Add Annotations from the Polyspace Interface

This method shows you how to convert review comments and classifications in the Polyspace interface into code annotations.

On the Results List or Result Details pane, assign a Severity, Status, and Comment to a result.
1. Click a result.
2. From the Severity and Status dropdown lists, select an option.
3. In the Comment field, enter a comment or keyword that helps you easily recognize the result.
On the Results List pane, right-click the commented result and select Add Pre-Justification to Clipboard. The software copies the severity, status, and comment to the clipboard.
Right-click the result again and select Open Editor. The software opens the source file to the location of the defect.
Paste the contents of your clipboard on the line immediately before the line containing the defect or coding rule violation.
You can see your review comments as a code comment in the Polyspace^® annotation syntax, which Polyspace uses to repopulate review comments on your next analysis.
Save your source file and rerun the analysis.
On the Results List pane, the software populates the Severity, Status, and Comment columns for the defect or rule violation that you annotated. These fields are read only because they are populated from your code annotation. If you use a specific keyword or status for your annotations, you can filter your results to hide or show your annotated results. For more information on filtering, see Filter and Group Results in Polyspace Desktop User Interface.

Add Annotations Manually

This method shows you how to enter comments directly into your source files by using the Polyspace code annotation syntax. The syntax is not case-sensitive and applies to the first uncommented line of C/C++ code following the annotation.

Open your source file in an editor and locate the line or section of code that you want to annotate.
Add one of the following annotations:
- For a single line of code, add the following text directly before the line of code that you want to annotate.
```
/* polyspace<Type:Kind1[,Kind2] : [Severity] : [Status] > [Notes] */
```
- For a section of code, use the following syntax.
```
/* polyspace:begin<Type:Kind1[,Kind2] : [Severity] : [Status] > [Notes] */

... Code section ...

/* polyspace:end<Type:Kind1[,Kind2] : [Severity] : [Status] >  */
```
  If a macro expands to multiple lines, use the syntax for code sections even though the macro itself covers one line. The single-line syntax applies only to results that appear in the first line of the expanded macro.

Replace the words Type, Kind1, [Kind2], [Severity], [Status], and [Additional text] with allowed values, indicated in the following table. The text with square brackets [] is optional and you can delete it. See Syntax Examples.

Word	Allowed Values
`Type`	The type of results: `Defect` (Polyspace Bug Finder™) `RTE`, for run-time checks (Polyspace Code Prover™) `VARIABLE`, for global variables (Polyspace Code Prover) `CODE-METRIC`, for code complexity metrics. `MISRA-C`, for MISRA C:2004 `MISRA-AC-AGC` `MISRA-C3`, for MISRA C:2012 `MISRA-CPP` `JSF` `Custom`, for custom coding rule violations.
`Kind1,[Kind2],...`	For defects, run-time checks and code metrics, use the short names of checkers. See: Short Names of Bug Finder Defect Groups and Defect Checkers Short Names of Code Prover Run-Time Checks (Polyspace Code Prover) For coding rule violations, specify the rule number or numbers. For global variables, the only allowed value is `ALL`. If you want the comment to apply to all possible defects or coding rules, specify `ALL`.
`Severity`	Text that indicates how critical you consider the defect. Enter one of the following: `Unset` `High` `Medium` `Low` This text populates the Severity column on the Results List pane.
`Status`	Text that indicates how you intend to correct the error in your code. Enter one of the following or any other text: `Unreviewed` `To investigate` `To fix` `Justified` `No action planned` `Not a defect` `Other` This text populates the Status column on the Results List pane. The status is also used in Polyspace Access to determine whether a result is justified. To justify a result, use `Justified`, `No action planned` or `Not a defect`.
`Notes`	Additional comments, such as a keyword or an explanation for the status and severity.

Syntax Examples

A single defect:

/* polyspace<Defect:HARD_CODED_BUFFER_SIZE:Medium:To investigate> Known issue */
int table[100];

A single run-time check:

/* polyspace<RTE: ZDV : High : To Fix > Denominator cannot be zero */
y=1/x;

A MISRA C:2012 rule violation:

/* polyspace<MISRA-C3: 13.1 : Low : Justified> Known issue */
int arr[2] = {x++,y};

Unused global variable:

/* polyspace<VARIABLE: ALL : Low : Justified> Variable to use later*/
int var_unused;

Multiple defects:

polyspace<Defect:USELESS_WRITE,DEAD_CODE:Low:No Action Planned> OK issue

Multiple JSF^® rule violations:
```
polyspace<JSF:9,13:Low:Justified> Known issue
```