Reviewing Findings

Relaxing findings

From Findings tab

If you realise that a violation found during an analysis is not justified, you can relax it from the Findings tab of the Explorer.

In the example below, we consider that a Backward goto violation should not be reported, because it is a Relaxed (False positive). Let’s start by locating the violation in the Findings tab:

Figure 1. The backward goto violation we want to relax

By clicking on the finding, you can display a sidebar details that provides more information and allows you to change the status of the finding:

Figure 2. The finding sidebar details

Click Edit to view the available statuses for the violation.

Figure 3. Changing finding status

Type a justification or comment for the relaxation and choose from one of the reasons for relaxing the violation:

Open is the default status for new findings, which means no relaxation
Open (Confirmed) means no relaxation, plus indicates that this finding has been reviewed and its status is validated as open.
Relaxed (Derogation) means that you are relaxing a true violation for an exceptional reason
Relaxed (False positive) can be used to work around a violation that was falsely detected by a Data Provider
Relaxed (Legacy system) is used when a violation is detected in a piece of code that was analysed but cannot or will not be fixed.

To add your own custom finding status in your model. See the Custom statuses section to know more.

In our example, select Relaxed (False positive), enter a comment and click Change. The Findings page will reload and the violation will be gone from the list.

Figure 4. The updated findings list after relaxing the backwards goto

Relaxed findings are never deleted. If you want to review the list of findings that were relaxed in your project, adjust the filter on the Findings tab to display relaxed findings, as shown below;

Figure 5. The filtered list of findings for the project, including the backwards goto Relaxed (False positive)

You can relax an individual finding, all findings for an artefact, or an entire rule at once. Note that instead of relaxing a rule, you can deactivate rules by using the Ruleset Editor (see Ruleset Editor).

If you are looking to relax entire artefacts instead of findings, you can do that from the Artefact Tree , as described in Relaxing and excluding artefacts).

From source code view

You can also relax Findings from the Source Code view. In View Source Code, Some Findings are directly indicated in the Source Code view with a Warning sign

Figure 6. The warning sign indicates the presence of a Finding

By clicking on one Finding Warning sign, and then See more you will be redirected to the finding sidebar details from where you will be able to work on the finding:

Figure 7. Finding shortcut menu

From here, you can see basic information about your Finding: Rule, Mnemonic, Rule description, Finding description and the Data Provider which emitted it. You can also relax your findings from there:

As in Findings tab, type a justification or comment for the relaxation and choose from one of the reasons for relaxing the violation:

Open is the default status for new findings, which means no relaxation
Open (Confirmed) means no relaxation, plus indicates that this finding has been reviewed and its status is validated as open.
Relaxed (Derogation) means that you are relaxing a true violation for an exceptional reason
Relaxed (False positive) can be used to work around a violation that was falsely detected by a Data Provider
Relaxed (Legacy system) is used when a violation is detected in a piece of code that was analysed but cannot or will not be fixed.

To add your own custom finding status in your model. See the Custom statuses section to know more.

Then, click on the button to validate the relaxation.

From source code file

Squore provides a violation relaxation mechanism that is triggered via comments found in the source code itself. Squore interprets comments formatted in one of these three ways:

Inline Relaxation

This syntax is used to relax violations on the current line.
```
some code; /* %RELAX<keys> : Text to justify the relaxation */
```
Relax Next Line

This syntax is used to relax a violation on the first following line that is not a comment. In the example the text of the justification will be: "Text to justify the relaxation the text of the justification continues while lines are made of comments only"
```
/* >RELAX<keys> : Text to justify the relaxation */
/* the text of the justification continues while */
/* lines are made of comments only */
some code;
```

Block Relaxation

This syntax is used to relax violations in an entire block of code.

/* {{ RELAX<keys> : Text to justify the relaxation */
/* like for format 2 text can be on more than one line */
int my_func() {
   /* contains many violations */
   ...
}
/* }} RELAX<keys> */

Violations <keys> can be one of the following:

<*>: relax all violations
<MNEMO>: relax violations of the rule MNEMO
<MNEMO1,MNEMO2,…,MNEMOn>: relax violations of rules MNEMO1 and MNEMO2 … and MNEMOn

Default relaxation status is "Relaxed (Derogation)", but it is possible to specify any other custom relaxation status defined in your model (Custom statuses). The syntax is the following:

some code; /* %RELAX:RELAXED_CUSTOM_STATUS<keys> : Text to justify the relaxation */

As an example, this is how you would relax the violations of the rule Backward goto for Maintainability Non-Conformity in Neptune:

click the violation of Backward goto on the Findings page to find the rule’s mnemonic (BWGOTO) and the location of the finding (DB5_backup.c line 52).

Figure 8. The details of the Backward goto violation

Edit the code of the sample project to relax the violation as shown below.

goto loopwrite; /* %RELAX<BWGOTO> : This backward goto is acceptable in our code. */

Create a new version of the project.
On the Findings page, the violation is now visible if you choose to display derogations in the filter:

Figure 9. The relaxed violation is visible when displaying derogations

Using the Relaxed in Sources toggle in the filter options, you can choose to show or hide violations that were relaxed in source code.

Suspicious findings

After you have relaxed or confirmed findings, Squore will check for source code changes around the location of the finding and flag it as suspicious in case of changes. The suspicious state is a flag that is automatically added to state of the findings (the state is not affected).

You can quickly see if you have suspicious findings in the Infos panel at the top of the page:

Figure 10. The Infos panel for projects containing suspicious findings

Clicking on the number of Suspicious allows to filter directly on the suspicious finding and focus on them.

To see suspicious findings in action, we will relax the Missing Break at line 40 in audio/a_bus.c in the project called Saturn. Click the Current node in the portfolio, find the artefact in the project and enter a relaxation comment for the Missing Break at line 40:

Figure 11. Relaxing the Missing Break at line 40

When saving the finding relaxation, the source code viewer changes the marker for the finding to a grey warning sign to indicate that the violation was relaxed.

Figure 12. Grey and yellow markers in the source code viewer for relaxed and normal findings

The next version of the file included in the library does not seem to include any fix for the specific violation, but instead uses a renamed variable in the artefact where the finding is:

static inline int __bus_run_fx(int bus, int in_slot, int *busses[], unsigned frames)
{
	audio_bus_t *b = {bustab}[bus];
	--in_slot;	/* No IFX on in_slot 0! */
	switch(b->insert[in_slot].current_state)
	{
	  case FX_STATE_RUNNING:
	  case FX_STATE_SILENT:
	  case FX_STATE_RESTING:
		if(b->in_use)	/* Do we have input? */
			b->insert[in_slot].process({b}->insert[in_slot],
					busses[bus], frames);
		else
		{
			b->insert[in_slot].process_r({b}->insert[in_slot],
					NULL, busses[bus], frames);
			b->in_use = 1;
		}
		/* Check if the plugin actually produced valid output! */
		return (FX_STATE_RUNNING == b->insert[in_slot].current_state);
	  default:
		/* No plugin, or plugin not running. */
		return 0;
	}
}

Since the relaxed violation is still there, analysing this code triggers the suspicious finding warning in the web interface to alert you in case you need to revise the finding status now that the code has changed. Click on the number of Suspicious, to reveal the suspicious finding, as shown below:

Figure 13. Revealed suspicious findings using the warning banner

Note that the violation is still relaxed with the Relaxed (Legacy system) status, but the Suspicious flag was attached to it. Click the source code icon next to the finding to view the source code in this new version. The marker for the finding is now purple, which is the colour used to highlight suspicious findings:

Figure 14. Purple marker for suspicious findings in source code viewer

After reviewing the finding, you can remove the suspicious flag by opening the Edit dialog again and change the relaxation status or comment, or just remove the suspicious flag:

Figure 15. Removing the suspicious flag of a finding

When you save your changes, the suspicious warning banner disappears, as there are no more suspicious findings to review in the project.

Detection of suspicious findings is activated by default and is a parameter of Squore Analyzer that can be tweaked by modifying the following parameters in the project wizard:

Figure 16. The settings for suspicious finding detection in Squore Analyzer

Adding findings manually

If you notice that a violation in the code or an issue in the project was not detected during an analysis, you can decide to create a finding manually from the Artefact Tree.

This feature, like the creation of manual artefacts (see Adding and removing artefacts manually) is only available if your model was configured to support it. Consult your Squore administrator to verify if it is available in your configuration.

In this example, we add a finding to notify of a documentation issue in the Neptune project. Click on the Current version of the project, and display the menu for the artefact where you consider that the documentation is wrong.

Figure 17. The artefact menu with the Add a finding… option highlighted

When you click the Add a finding… option, a dialog appears and lets you select the type of finding to add, as well as a description of the issue:

Figure 18. The Add a finding… popup

Click Add to save the finding. You can check that it was added successfully in the Findings tab of the Explorer:

Figure 19. The Findings tab showing the manually added finding

Manual findings are displayed automatically in the Findings tab like other findings. If you want to filter them, use the advanced filter and select or exclude [Manual] in the Data Provider category.

Like regular findings, your finding also displays in the source code viewer, as shown below:

Figure 20. The documentation issue is visible on line 1 of the file it was added to

It is also possible to add a manual finding directly from the source code view. To do so, click on the code line number where you want to add the manual finding. The finding adding form is displayed. Firstly, you have to select the finding rule among the manual rules, then you have to fill the new finding description. Both fields are required. Finally, confirm the new manual finding addition thanks to the "Add a finding" button.

Figure 21. Adding a finding from the source code view