Import Review Information from Previous Polyspace Analysis have a problem.

Good morning!

I detect a problem related to "Import Review Information from Previous Polyspace Analysis" seem very dangerous.

When I run Code Prover on my source code, Code Prover show an Illegally dereference pointer in function X(). I investigate this warning but it not a defect so I set status "Not a defect" and add comment for this warning. After that I try to change my source code to make this Illegally dereference pointer in function X() became a real defect and I run Code Prover again, but when I review the result, Code Prover not show any new warning, it still show an Illegally dereference pointer in function X() but with a status and comment I have added before. This seem very dangerous because when I have new version of source, after run it with Code Prover, I only care the "new warning" from the result, so that problem can make I miss many defects on my source code. Do you have any suggestion?

Answer 1

[Anirban]

Hi Hong,

Your concern is valid. The review information is indeed imported if the content of a line does not change and shows the same result as before. In unlikely scenarios, it might happen that you get the same result on the same line despite changing previous lines that lead to the result. Your review information from a previous analysis is then imported to the new result. The expectation is that if you justified the previous result with a status such as Not a defect, it is likely that you want to continue to justify the new result. For instance, if you accepted an overflow previously because you accounted for a wrap-around behavior after the overflow, you are likely to accept the overflow whatever the cause. However, in a few cases, you might want to review the result again and might miss the fact that the result merits another review. To avoid this situation:

• Use careful judgement when justifying non-local results that are related to previous events.
• For critical components, conduct periodic assessments of justified results to see if the justifications still apply. Such an assessment is useful specially for the Code Prover run-time checks.

One possible workflow is to use different statuses for different reasons:

• Use 'Not a defect' only if you want to justify a result no matter what the cause. This would be the case, for instance, if you have accounted for an issue downstream and you think it would be always accounted for. If you use Bug Finder or check for MISRA standard violations, quite a few issues are very local, and you would use this status for those issues.
• Use another existing status if you want to justify a result in the current context, but if the context changes, you might take the result more seriously. You can create your own statuses, too. In the Polyspace user interface, select Tools > Preferences and create your own status. See more details in Customize Polyspace User Interface.

Then, you can safely filter out issues with 'Not a defect' status, but periodically assess the issues with the other status.

[Tran Thang]

Hi Aniban,

We use Code Prover to analysis a big source code (~3000 orange warnings) and when have new version of source code, we run it with Code Prover and check how many new warnings appear and we analysis it (it perfect only when Code Prover can import previous review exactly, unlike the way Code Prover does now). We don't have enough time and we don't want re-analysis ~3000 warnings, we just want analysis "new real warning". When your team develop feature "Import Review Information from Previous Polyspace Analysis", I think your team must thinking about this problem in a big source code, because this can make miss many defects.

[Anirban]

Hi Hong,

As far as I am aware, the product does not yet give an out-of-the-box solution to bypass comment import as long as the content of a line stays the same and the same issue appears on the same token of that line as a previous analysis (but preceding source code changed). The comment import does not use semantic information as of the current release. You can, of course, choose to not import comments at all from a previous analysis, but that is not practical.

However, this does not mean you will miss defects when all your previous review information gets imported. This capability can be achieved in other ways.

If you contact Technical Support, using the current features of the product, they can show you a way to set up a review workflow with the right filters so that you can easily see real new warnings without much effort.