MATLAB: Open Polyspace R2016a results in R2015a

polyspacePolyspace Code ProverPolyspace Code Prover Server

Hi,

I ran some verifications using R2016a, however the tool mandated by my project is R2015a. I really don't want to go back and write all my justifications again and so I wondered if there was a way to open these results in the older version.

Currently I get an encoding error as seen here:

Best Answer

Hi,

the error message is a consequence of loading results generated with a more recent version than the current product (in this case loading R2016a results with the R2015a product).

The product is not "forward compatible": it is not possible to load results from a more recent version, basically because the format of the results evolve from versions to versions. New kinds of results may appear with new versions, that will then be unknown to older versions.

We guarantee backward-compatibility but not forward compatibility.

Alex

Related Solutions

MATLAB: What version of Polyspace contains Code Prover Rev. 1.6

Hello,

I guess that by "revision" you mean the revision number that can be found in the project file (.psprj or .cfg). Here is a list of the Polyspace project versions and their revision number:

 R2012b : 1.3 
 R2013a : 1.3 
 R2013b : 1.4 
 R2014a : 1.5 
 R2014b : 1.5 
 R2015a : 1.5 
 R2015b : 1.5 
 R2016a : 1.6

As you can seen, 1.6 corresponds to R2016a.

Best regards,

Alexandre

MATLAB: Import Review Information from Previous Polyspace Analysis have a problem.

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.

Best Answer

Related Solutions

MATLAB: What version of Polyspace contains Code Prover Rev. 1.6

MATLAB: Import Review Information from Previous Polyspace Analysis have a problem.

Related Question