Skip to Main Content Skip to Search
Product Documentation

Version 7.2 (R2010a) Polyspace for C/C++ Products

This table summarizes what's new in V7.2 (R2010a):

New Features and ChangesVersion Compatibility ConsiderationsFixed Bugs and Known Problems
Yes
Details below		Yes—Details labeled as Compatibility Considerations, below. See also Summary.Includes fixes:
Polyspace Client for C/C++ Bug Reports
Polyspace Server for C/C++ Bug Reports

New features and changes introduced in this version are organized by product:

Polyspace Client for C/C++ Product

License Activation

Polyspace products now support the MathWorks software activation mechanism.

Activation is a process that verifies licensed use of MathWorks products. The process validates your product licenses and ensures that they are used correctly. You must complete the activation process before you can use Polyspace software.

The easiest way to activate the software is to log in to your MathWorks Account during installation. At the end of the installation process, the Polyspace Software Activation dialog box opens.

Follow the prompts in the Polyspace Software Activation dialog box to complete the activation process.

If you do not have a MathWorks account, you can create one during the activation process. To create an account, you must have an Activation Key, which identifies the license you want to install and activate.

If your Polyspace system is not connected to the internet, you can access the MathWorks License Center on a computer with internet access, activate your license, and download a license file for transfer to your Polyspace system. If you do not have access to a computer with an Internet connection, contact Customer Support.

For more information on how to activate your software, see Activating Polyspace Softwarein the Polyspace Installation Guide.

For more information on software activation, including frequently asked questions, refer to the MathWorks Web site:
www.mathworks.com/support/activation/polyspace.html

MISRA C++ Checker

Polyspace software can now analyze your C++ code to check compliance with the MISRA C++ coding standard.

The Polyspace MISRA C++ checker provides messages when MISRA C++ rules are not respected. Most messages are reported during the compile phase of a verification.

The MISRA C++ checker can check 167 of the 183 statically enforceable MISRA C++ coding rules.

For more information, see Checking Coding Rules, in the PolySpace Client/Server for C++ User Guide.

Source Code Comments

Polyspace software now allows you to place comments in your code that provide information about known coding rule violations and run-time errors. You can use these comments to

This information can then make the review process quicker and easier by allowing you to focus on new coding rule violations and run-time errors. .

When you review verification results, the Viewer displays comments on individual checks. You can then skip these commented checks, or simply use them as additional information during your review.

The coding rules log in the Launcher displays comments regarding coding rules. You can use these comments to filter out commented violations from the results, or simply to provide additional information on specific violations.

For more information, see Highlighting Known Coding Rule Violations and Run-Time Errors in the PolySpace Products for C User's Guide.

Importing Review Comments

New Import/Export checks and comments report allows you to you to compare the source code and verification results from a previous verification to the current verification, and highlights differences in the results.

Importing review comments from a previous verification can be extremely useful, since it allows you to avoid reviewing checks twice, and to compare verification results over time. However, if your code has changed since the previous verification, or if you have upgraded to a new version of the software, the imported comments may not be applicable to your current results. For example, the color of a check may have changed, or the justification for an orange check may no longer be relevant to the current code.

Use the Import/Export checks and comments report to highlight these differences, and focus on unreviewed results.

For more information, see Importing and Exporting Review Comments in the Polyspace Products for C/C++ User's Guide.

Compatibility Considerations.  In previous releases, when you specified the option -keep-all-files, it was possible to add comments to the results for a specific verification level (for example, pass2) , and then import them into another set of results (for example pass4) in the same results folder.

This is no longer possible in R2010a.

Data Range Specifications (DRS) Enhancements

Enhanced Data Range Specifications, including new format and workflow.

The Polyspace Data Range Specifications (DRS) feature now allows you to set constraints on data ranges using a new graphical user interface. When you enable the DRS feature, Polyspace software analyzes the files in your project, and generate a DRS template containing all the global variables, user defined functions, and stub functions for which you can specify data ranges.

To specify data ranges, you then edit this template using the Polyspace DRS configuration interface.

In addition, the DRS feature now allows you to specify constraints for additional types of data, including:

For more information, see Specifying Data Ranges for Variables and Functions (Contextual Verification) in the PolySpace Products for C User's Guide.

Compatibility Considerations.  Symbols ranged by DRS (init, permanent or globalassert mode) are no longer ignored by the main-generator. This can lead to differences in values and colors, for example full range instead of 0, or orange instead of green.

Pointer Information in the Viewer

Enhanced ToolTips in the Viewer now display pointer information, in addition to data ranges.

The software now provides, through tooltip messages, useful information about pointers to variables or functions. You see this information in the source code view when you place your cursor over a pointer, dereference character, function call, or function declaration. In addition, if you click a pointer check, dereference character, function call, or function declaration, the software displays pointer information in the selected check view.

For more information, see Using Pointer Information in Results Manager Perspective in the PolySpace Products for C User's Guide.

Enhanced Call Tree View and Variables View (Data Dictionary)

Enhanced user interface of the Call Tree View and Variables View improves navigation and usability.

In the Call Tree View, you can now double click any function call to go directly to the function definition.

In the Variables View, you can now right-click a variable to show legend information, and can open the concurrent access graph for a variable directly from the Variables View.

For more information, see Exploring the Results Manager Perspective in the PolySpace Products for C User's Guide.

Enhanced Search Function in Viewer

Enhanced Search feature in the Viewer improves navigation in your results.

The Viewer toolbar now contains a Search interface. This allows you to quickly enter search terms, specify search options, and set the scope for your search.

For more information, see Exploring the Results Manager Perspective in the PolySpace Products for C User's Guide.

Filtering Orange Checks in Viewer (C only)

Polyspace verification now identifies orange checks caused by input data. The software provides additional information on these orange checks, and allows you to hide them in the Viewer.

Verification can identify orange checks caused by:

When the software identifies this type of orange check, the Viewer provides information on its cause.

The Polyspace code verification log file also lists possible sources of imprecision for orange checks.

In addition, you can now hide these types of orange checks in the Viewer. When using Expert mode, click the filter button to hide oranges impacted by input data.

For more information, see Working with Orange Checks Caused by Input Data in the PolySpace Products for C User's Guide.

Methodological Assistant Enhancements

Enhanced Methodological Assistant in the Viewer.

The Methodological Assistant now allows you to define either a minimum percentage of orange checks to review, or a specific number of orange checks to review. This makes it easier to set specific quality criteria for your code at each level of review.

In addition, the Methodological Assistant now presents checks in a more logical order. Checks that are most likely to reveal bugs appear first, while non-useful checks no longer appear.

The new order of checks is:

  1. All red checks (an error always occurs)

  2. Orange checks known to produce errors in some situations (dark orange). For example, red for one call to a procedure and green for another.

  3. Some gray checks (UNR checks)

  4. Other orange checks (depending on the methodology and criterion level)

Most gray checks no longer appear in the Methodological Assistant, since reviewing many gray checks that occur after a red check is not useful. Only UNR checks that are not nested within dead code blocks appear in assistant mode.

Compatibility Considerations.  The number of checks presented for review in Assistant mode is different than in previous releases, since most gray checks no longer appear. In addition, the order in which you review checks is different.

Class Analyzer Enhancements for C++

Enhanced class analyzer can analyze a file with more than one class.

Unit-by-unit verifications can now verify files containing more than one class. Every class and function out of class contained in such files is now verified.

For more information, see PolySpace Class Analyzer in the PolySpace Client/Server for C++ User Guide.

Compatibility Considerations.  In -unit-by-unit mode, files that previously were not verified because they contained more than one class are now verified.

Change to Time Format in Log File

The time format reported in the log file has been updated to provide more information.

Example of new line (R2010a and later):
User time for polyspace-c: 00:02:24 (144.6real, 144.6u + 0s (0.3gc))

Example of old line (R2009b and earlier):
User time for rte-kernel: 4684.4real, 4319.2u + 324.6s (0.3gc)

Compatibility Considerations.  The new time format can impact some scripts that summarize information from the log file.

Merging of OVFL and UNFL Checks

Overflow (OVFL) and underflow (UNFL) checks have been merged into a single OVFL check. This reduces the number of orange checks you need to review, while continuing to provide the same information.

For red and orange checks, the check message provides the bounds that cause the overflow.

Compatibility Considerations.  The Selectivity rate of your results may change when compared to previous versions of the software. Underflows and overflows are now identified as a single check, so the Selectivity will decrease if the checks were green (2 green checks become 1 green), but will increase if the checks were both orange (2 orange checks become 1 orange).

Improved UNR Checks

Enhanced unreachable code (UNR) checks now provide additional information to help you understand the results. UNR checks now include information on:

For example: 

// UNR (unreachable code) => UNR (unreachable code) 		\
(end of block at line YYY)

// UNR (unreachable code) => UNR (unreachable code) 		\
(condition at line XXX, column AAA) ?

In addition, verification now reports new UNR checks on:

For more information on these new checks, see Changes to Verification Results.

Compatibility Considerations.  The number of checks in your verification results may change due to the new UNR checks.

Changes to Verification Results

Compatibility Considerations.  Verification results may change when compared to previous versions of the software. Some checks may change color, and the Selectivity rate of your results may change.

Refer to the following sections for information on the specific changes.

Merging of OVFL and UNFL Checks.  Overflow (OVFL) and underflow (UNFL) checks have been merged into a single OVFL check. This reduces the number of orange checks you need to review, while continuing to provide the same information.

For red and orange checks, the check message provides the bounds that cause the overflow.

The Selectivity rate of your results may change when compared to previous versions of the software.

New Gray (UNR) Checks on return, break, goto, and continue Statements.  Verification now reports gray UNR checks on unreachable statements after return, break, goto, and continue statements.

For example:

67 switch (counter) { 
68 	case 0: 
69 		counter = 0; 
70 		break; 
71	case 1: 
72		counter = 2; 
73		break; 
74 		counter = 2; /* unreachable code ! */ 
75 		break;

The number of checks in your verification results may increase due to these new UNR checks.

New Gray (UNR) Check on If Statement Without Else.  Verification now reports a gray UNR check on an if statement when the if condition is always true and if there is no else statement.

This allows you to find if branches that are always reachable, even when there is no else.

For example:

if (true()) 	// UNR if-condition always evaluates to true
	{ 
		// ... 
	}

The number of checks in your verification results may increase due to new UNR checks.

Nested Gray (UNR) Checks No Longer Appear in Reports.  Nested UNR checks in unreachable blocks no longer appear in the Methodological Assistant, or in generated reports.

The number of checks in generated reports may decrease due to elimination of these checks..

Dead Code on Else Branch.  Verification now reports gray UNR checks on empty branches.

For example:

void fct (void) 
{ 
	int a = 1; 
	if (a){ 
		a++; 
	} 
	else // ==> Now gray UNR 
	{ 
	// dummy 
	} 
}

The number of checks in your verification results may increase due to the new UNR check on empty branches.

Data Ranges for Fields of Structures (C).  Symbols ranged by DRS (init, permanent or globalassert mode) are now considered by the main-generator.

In previous releases, if DRS provided ranges for some fields of a structure, the other fields (not ranged by DRS) were not initialized by the main-generator, and therefore had an initial value of 0.

For example:

// DRS: s.x 0 10 init 

struct { int x; int y; } s; 
int foo(void) 
{ 
  return s.y; // y value: 0, full-range expected 
}

Symbols ranged by DRS are no longer ignored by the main-generator. This can lead to differences in values and colors, for example full range instead of 0, or orange instead of green.

Functions Called Before Main in Unit-by-unit Verification (C++).  The behavior of the option -function-called-before-main has changed for unit-by-unit verifications of C++ code.

When you set the option -function-called-before-main in unit-by-unit mode:

In previous releases, the init function was always called after constructor calls for each class.

Verification results may change when compared to previous versions of the software, due to changes in the call sequence.

Main Generator Initialization of Function Pointers.  The main-generator now initializes function pointers with default-mode stubs instead of pure stubs.

In previous releases, the main-generator initialized function pointers with pointers to pure functions.

This change may lead to differences in the color of checks in your results. For example:

int x; 
  s->fptr(&x); 
  read(x); // LNIV red with 9b -> orange with 10a

OVFL Check on Array Index Removed.  In previous releases, verification reported an overflow (OVFL) check on pointer/array dereference. However, this overflow never occurred if there was an OBAI problem first. Therefore, the check was not useful.

In R2010a, the OVFL check no longer appears on array index, the check has been merged into the OBAI check.

For example, in the following code there is no OVFL check on the array index. 

int main(void) 
{ 
   volatile int i,x; 
   int tab[10]; 

   x = tab[i]; 

}

The Selectivity of your results may change when compared to previous versions of the software. The OVFL check on array access has been merged into the OBAI check, so there are fewer checks reported. Selectivity will increase if the overflow check was orange, but will decrease if the OVFL check was green.

IDP Check on Local Member Access Removed (C++).  Verification no longer reports an IDP check on local member access.

In previous releases, verification reported an IDP check. This IDP appeared on the "." when accessing the field of an object returned by copy construction.

For example:

struct C { 
  C(const C&c1) { k =c1.k; } 
  C() { k = 0 ;} 
  int k ; 
} ; 

C g() { 
  C ret ; 
  ret.k = 2 ; // IDP on "." here 
  return ret; 
} 

int main() { 
  C c = g() ; 
}

However, this check was caused by an internal pointer and was not useful.

The Selectivity of your results may change when compared to previous versions of the software.

OBAI Check on Dynamic Initialization of Array Removed (C++).  Verification no longer reports an OBAI check on dynamic initialization of array.

In previous releases, verification reported an OBAI check. The OBAI check appeared on dynamic initialization of array with an aggregate.

For example:

nt main(void) 
{ 
  float tab[] = // extra green obai check 
    { 
      4.3, 
      0.0F 
    }; 

  return 0; 
}

However, this check was caused by an internal translation and was not useful.

The Selectivity of your results may change when compared to previous versions of the software.

Duplicate Checks in For/While Loops Removed.  Verification no longer reports duplicate checks in condition expression of for and while loops.

Any duplicate checks on a loop condition are now merged in a single check, except when condition expression is complex.

Due to the reduction in the number of checks, the selectivity of your results may change when compared to previous versions of the software.

malloc(0) Limitation Removed.  Verification no longer has a limitation when malloc(0) returns a null pointer.

In previous releases, verification reported a green check on the following code: 

assert(malloc(0) == NULL) ;

However, this construction could fail. The software now correctly verifies this construction.

Verification results may change when compared to previous versions of the software.

Change in OOP on Deletion of Null Pointer (C++).  Verification no longer reports a red OOP check when deleting a null pointer.

In previous releases, verification reported a red OOP check on the following code: 

struct A { 
  virtual void f() { } 
  ~A() { } 
} ; 

int main() { 
  A* pa ; 
  if (0) pa = (A*) 0Xfff; 
  pa = 0; 
  delete pa ; // red OOP
}

However, calling "delete" on a null pointer is allowed. The red OOP when deleting a null pointer is now gray.

Verification results may change when compared to previous versions of the software.

Change to IDP Check When Accessing a Field of an Inherited Class (C).  Verification no longer reports a red IDP check when accessing a field of an inherited class with an mcpu target.

In previous releases, verification reported a red IDP check.

For example:

struct Val { 
	int val; 
}; 

struct Left : virtual Val { 
	int left; 
	virtual int get_left() { return left; }	// polymorphic:yes 
}; 

struct Right : virtual Val { 
	int right; 
	virtual int get_right() { return right; } 
}; 

struct S : Left, Right {      // multiple:yes 
}; 

S s = S(); 
Left& le = s;         // intermediate:global, reference:yes 
Right& re = s;         // intermediate:global, reference:yes 

int main(void){ 
  assert(re.val == 0);    // Unexpected red IDP 
}

However, this was not actually an error. The check is no longer red.

The color of the IDP check has changed when compared to previous versions of the software.

Changes to Coding Rules Checker Results

Compatibility Considerations.  Due to changes in the coding rules checker, the number of coding rule violations may change when compared to previous versions of the software.

Refer to the following sections for information on the specific changes.

MISRA-C Rule 10.1 Violations on Constant Operands.  The MISRA-C checker no longer reports errors for rule 10.1, "The value of an expression of integer type shall not be implicitly converted to a different underlying type," for certain constructions. For example: 

int i; 
for (i = 0; i < 12; i++)

An integer constant that fits into the size of a char is now seen as a signed char whatever the sign of char (this depends on the selected target or is set by option).

If you use the options -target powerpc or -default-sign-of-char unsigned, the coding rules checker will report fewer violations of MISRA-C rule 10.1 on constant operands.

MISRA-C Rule 12.5 Violation Report Improved.  The coding rules checker now reports a column number for violations of MISRA-C rule 12.5.

You may see more violations of rule 12.5, since two violations that occur on same line but in different columns are now identified separately.

MISRA-C Rule 7.1 Violations on File Names of Preprocessed Files.  The coding rules checker no longer reports violations of MISRA-C rule 7.1 on the names of internal preprocessing files. These violations occurred in projects containing Japanese characters.

You may see fewer violations of rule 7.1 in MISRA reports.

MISRA-C Rule 5.4 Violations on Anonymous Structures and Unions.  The coding rules checker no longer reports violations of MISRA-C rule 5.4 on anonymous struct/union fields.

You may see fewer violations of rule 5.4 in MISRA reports.

JSF Rule AV-151 Violations on Evaluation of Constant.  The coding rules checker no longer reports violations of JSF rule AV-151 on internal evaluation of a constant value, for example when there is an expression in an enum list.

You may see fewer violations of rule AV-151 in JSF reports.

Enumerated Types Support

The option -enum-type-definition allows verification to use different base types to represent an enumerated type, depending on the enumerator values and the selected definition.

When using this option, each enum type is represented by the smallest integral type that can hold all its enumeration values.

Possible values are:

For more information, see Enum type definition (-enum-type-definition) in the PolySpace Products for C Reference.

New Target Processor Support

Added support for the c18 24-bit target processor (C only).

For more information, see Predefined Target Processor Specifications in the PolySpace Products for C Reference.

Operating System Support

Added support for the following Linux® distributions:

For more information, see the Polyspace Installation Guide.

Polyspace Server for C/C++ Product

License Activation

Polyspace products now support the MathWorks software activation mechanism.

Activation is a process that verifies licensed use of MathWorks products. The process validates your product licenses and ensures that they are used correctly. You must complete the activation process before you can use Polyspace software.

The easiest way to activate the software is to log in to your MathWorks Account during installation. At the end of the installation process, the Polyspace Software Activation dialog box opens.

Follow the prompts in the Polyspace Software Activation dialog box to complete the activation process.

If you do not have a MathWorks account, you can create one during the activation process. To create an account, you must have an Activation Key, which identifies the license you want to install and activate.

If your Polyspace system is not connected to the internet, you can access the MathWorks License Center on a computer with internet access, activate your license, and download a license file for transfer to your Polyspace system. If you do not have access to a computer with an Internet connection, contact Customer Support.

For more information on how to activate your software, see Activating Polyspace Softwarein the Polyspace Installation Guide.

For more information on software activation, including frequently asked questions, refer to the MathWorks Web site:
www.mathworks.com/support/activation/polyspace.html

Queue Manager Interface

The Polyspace Queue Manager Interface (Spooler) is now available on Linux machines, providing a graphical interface for managing verification jobs on the Polyspace server.

For more information, see Managing Verification Jobs Using the Polyspace Queue Managerin the Polyspace Products for C/C++ User's Guide or Polyspace Products for C++ User's Guide.

Operating System Support

Added support for the following Linux distributions:

For more information, see the Polyspace Installation Guide.

  

Version 5.6 (R2010b) Polyspace Model Link ProductsVersion 5.6 (R2010b) Polyspace Model Link Products Version 5.5 (R2010a) Polyspace for Ada and Model Link ProductsVersion 5.5 (R2010a) Polyspace for Ada and Model Link Products

 © 1984-2012- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS