Qualkitdo Codeprover Tor PDF

DO Qualification Kit
Polyspace® Code Prover™

Tool Operational Requirements
R2015a, March 2015

How to Contact MathWorks
Latest news: www.mathworks.com
Sales and services: www.mathworks.com/sales_and_services
User community: www.mathworks.com/matlabcentral
Technical support: www.mathworks.com/support/contact_us
Phone: 508-647-7000
The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
DO Qualification Kit: Polyspace® Code Prover™ Tool Operational Requirements

© COPYRIGHT 2013–2015 by The MathWorks, Inc.
The software described in this document is furnished under a license agreement. The software may be used or copied only under
the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written
consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the
federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees
that this software or documentation qualifies as commercial computer software or commercial computer software documentation
as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and
conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification,
reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or
other entity acquiring for or through the federal government)and shall supersede any conflicting contractual terms or conditions.
If this License fails to meet the government’s needs or is inconsistent in any respect with federal procurement law, the
government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a
list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective
holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more
information.
Revision History
September 2013 New for Version 2.2 (Applies to Release 2013b)
March 2014 Revised for Version 2.3 (Applies to Release 2014a)
October 2014 Revised for Version 2.4 (Applies to Release 2014b)
March 2015 Revised for Version 2.5 (Applies to Release 2015a)
Contents
1 Introduction ...................................................................................................................................... 1-1
1.1 Polyspace Code Prover Product Description ........................................................................... 1-2
1.2 General Points of Document ................................................................................................... 1-3
2 Polyspace Code Prover for C Operational Requirements ................................................................ 2-1
2.1 Input Requirements ................................................................................................................. 2-2
2.1.1 Input Requirements for Analysis Mode ......................................................................... 2-2
2.1.2 Input Requirements on Code Directives ...................................................................... 2-32
2.1.3 Input Requirements for Analysis Precision ................................................................. 2-33
2.1.4 Input Requirements for Information ............................................................................ 2-37
2.1.5 Input Requirements for Scaling Options ...................................................................... 2-38
2.1.6 Input Requirements for Tasking .................................................................................. 2-40
2.1.7 Miscellaneous .............................................................................................................. 2-41
2.2 Output Requirements ............................................................................................................. 2-46
2.2.1 Output Requirements for Call Graphs ......................................................................... 2-46
2.2.2 Output Requirements for Data Dictionaries ................................................................. 2-46
2.2.3 Miscellaneous .............................................................................................................. 2-47
2.3 Performance Requirements ................................................................................................... 2-49
2.3.1 Polyspace Code Prover Time Increase Threshold ....................................................... 2-49
2.4 Language-Specific Requirements .......................................................................................... 2-50
2.4.1 Semantic Requirements ............................................................................................... 2-51
2.4.2 Applicable Checks for C Polyspace Code Prover ........................................................ 2-52
2.5 Traceability Matrix HLR/OR and LSR ................................................................................. 2-56
2.6 Polyspace Products for C Appendixes .................................................................................. 2-57
2.6.1 Description of Call-Graph File .................................................................................... 2-57
2.6.1.1 File Description .................................................................................................. 2-57
2.6.1.2 Fields Description .............................................................................................. 2-58
2.6.1.3 Example.............................................................................................................. 2-59
2.6.2 Description of Data-Table File .................................................................................... 2-60
2.6.2.1 File description ................................................................................................... 2-60
2.6.2.2 Fields description ............................................................................................... 2-60
2.6.2.3 Example.............................................................................................................. 2-64
2.6.3 Fully or Partailly Implemented MISRA-C:2004 Rules................................................ 2-64
2.6.4 Predefined MISRA-C:2004 Rules Subsets .................................................................. 2-64
2.6.5 Fully or Partially Implemented MISRA-C:2012 Coding Directives and Rules ........... 2-64
2.6.6 Predefined MISRA-C:2012 Rules Subsets .................................................................. 2-64
2.6.7 Options-ORs Correspondance ..................................................................................... 2-65
2.6.8 Keil & IAR Extensions ................................................................................................ 2-68
2.6.9 Warning/error messages format in the log file ............................................................. 2-70
2.6.10 Description of PSCP file ......................................................................................... 2-70
v
2.6.11 Description of the Extended DRS format ............................................................... 2-73
2.6.11.1 General information ........................................................................................... 2-73
2.6.11.2 Syntax description – XML Marks ...................................................................... 2-73
2.6.11.3 Syntax description – XML Elements ................................................................. 2-74
2.6.11.4 Valid modes and default values .......................................................................... 2-76
2.6.12 Description of the Code metrics .............................................................................. 2-78
2.6.12.1 Definition and implementation ........................................................................... 2-78
2.6.12.2 File format .......................................................................................................... 2-78
3 Polyspace Code Prover for C++ Operational Requirements ............................................................ 3-1
3.1 Input Requirements ................................................................................................................. 3-2
3.1.1 Input Requirements for Analysis Mode ......................................................................... 3-2
3.1.2 Input Requirements on Code Directives ...................................................................... 3-26
3.1.3 Input Requirements for Precision of Analysis ............................................................. 3-28
3.1.4 Input Requirements for Information ............................................................................ 3-30
3.1.5 Input Requirement for Scaling Options ....................................................................... 3-31
3.1.6 Input Requirements for Tasking .................................................................................. 3-33
3.1.7 Miscellaneous .............................................................................................................. 3-33
3.2 Output Requirements ............................................................................................................. 3-38
3.2.1 Output Requirements for Call Graphs ......................................................................... 3-38
3.2.2 Output Requirements for Data Dictionaries ................................................................. 3-38
3.2.3 Miscellaneous .............................................................................................................. 3-39
3.3 Performance Requirements ................................................................................................... 3-41
3.3.1 Polyspace Code Prover Time Increase Threshold ....................................................... 3-41
3.4 Language-Specific Requirements .......................................................................................... 3-42
3.4.1 Semantic Requirements ............................................................................................... 3-43
3.4.2 Applicable Checks for C++ Polyspace Code Prover ................................................... 3-45
3.5 Traceability Matrix HLR/OR and LSR ................................................................................. 3-64
3.6 Polyspace Products for C++ Appendixes .............................................................................. 3-65
3.6.1 Description of Call-Graph File .................................................................................... 3-65
3.6.1.3 Example.............................................................................................................. 3-66
3.6.2 Description of Data-Table File .................................................................................... 3-67
3.6.2.3 Example.............................................................................................................. 3-71
3.6.3 JSF++ Rules ................................................................................................................. 3-72
3.6.4 Warning/Error Messages Format In The Log File ....................................................... 3-72
3.6.5 Description of PSCP file .............................................................................................. 3-72
3.6.6 MISRA C++ Rules ...................................................................................................... 3-75
vi
4 Polyspace Code Prover User Information ........................................................................................ 4-1
5 Installation ........................................................................................................................................ 5-1
6 Operational Environment ................................................................................................................. 6-1
7 References ........................................................................................................................................ 7-1
7.1 Applicable Documents for C ................................................................................................... 7-2
7.2 Applicable Documents for C++ .............................................................................................. 7-3
7.3 Applicable Rules for C and C++ ............................................................................................. 7-4
7.3.1 Polyspace Custom Rules ................................................................................................ 7-4
8 Definitions and Abbreviations ......................................................................................................... 8-1
8.1 Abbreviations .......................................................................................................................... 8-2
vii
viii
1 Introduction
This document comprises the Tool Requirements (reference DO-330 Section 10.2.1) for the
following capabilities of the Polyspace® Code Prover™ tool:
 Code verification
 Call tree computation
 Variable access pane
 Unreachable code analysis
This document describes the checks generated and the options available for the Polyspace Code
Prover.
The options described in this document are available using the batch mode of the tool, available
at Polyspace Code Prover startup (see OPREQS-IHM).
This document is intended for use in the DO-330 tool qualification process for TQL-4 tools.
1.1 Polyspace Code Prover Product Description
Prove the absence of run-time errors in software
Polyspace Code Prover proves the absence of overflow, divide-by-zero, out-of-bounds array
access, and certain other run-time errors in C and C++ source code. It produces results without
requiring program execution, code instrumentation, or test cases. Polyspace Code Prover uses
static analysis and abstract interpretation based on formal methods. You can use it on
handwritten code, generated code, or a combination of the two. Each operation is color-coded to
indicate whether it is free of run-time errors, proven to fail, unreachable, or unproven.
Polyspace Code Prover also displays range information for variables and function return values,
and can prove which variables exceed specified range limits. Results can be published to a
dashboard to track quality metrics and ensure conformance with software quality objectives.
Polyspace Code Prover can be integrated into build systems for automated verification.
Key Features
 Proven absence of certain run-time errors in C and C++ code

 Color-coding of run-time errors directly in code
 Calculation of range information for variables and function return values
 Identification of variables that exceed specified range limits
 Quality metrics for tracking conformance with software quality objectives
 Web-based dashboard providing code metrics and quality status
 Guided review-checking process for classifying results and run-time error status
 Graphical display of variable reads and writes
Given a source program P written in source programming language L, you want to compute
statically (without specific input data) and automatically a conservative model of the future
dynamic, run-time behavior of P. You also want to extract from this model predictions about the
possible occurrences of run-time errors and sources of nondeterminism (for static verification)
as well as data and control flow information.
The present document is derived from the High-Level Specification of Polyspace Code Prover,
and serves as a criterion for functional validation testing.
1-2
1.2 General Points of Document
This document will list two categories of requirements:
 General operational requirements (OR), most of which are programming language

independent
 Language-specific requirements (LSR)
The Operational Requirements are classified by software component and requirement category.
Requirement categories are one of the following:
 Tool input or semantic requirements

 Tool output
 Performances and resource consumption requirements
The general classification of ORs is as follows, where xx [0,99]
Polyspace Code Polyspace Code Polyspace

Prover Startup Prover Environment
Inputs/Semantics OR-1xx OR-3xx OR-5xx
Outputs/Resources OR-2xx OR-4xx OR-6xx
Performances OR-7xx OR-8xx OR-9xx
Polyspace Code Prover Tool Requirements are defined as Operational Requirements (ORs) and
Language Specific Requirements (LSRs) in this document. Polyspace Code Prover Tool
Operational Requirements are defined as High-Level Requirements (HLRs) in the Polyspace
Code Prover Theoretical Foundation document.
For traceability between the High-Level Requirments (HLRs), Operational Requirments (ORs)
and Language Specific Requirements (LSRs), please refer to
qualkitdo_codeprover_HLR_OR_LSR_Trace.xlsx
1-3
1-4
2 Polyspace Code Prover for C
Operational Requirements
The following sections list the Polyspace Code Prover for C capabilities that are supported by
the DO Qualification Kit. To claim certification credit, the user is responsible for determining
the applicability of the Polyspace Code Prover for C capabilities supported by the DO
Qualification Kit to their project.
2.1 Input Requirements
2.1.1 Input Requirements for Analysis Mode
OR-340: Polyspace Code Prover shall allow users to specify the application language
to analyze
 The user can specify the language analyzed with the option -lang.
 Polyspace Code Prover must verify that the language is C in a case-insensitive manner.
 If the language is different from C, Polyspace Code Prover must stop the execution and
display an error message.
OR-343: Polyspace Code Prover shall allow user to specify the application source files
 Polyspace Code Prover allows giving a list containing source files to analyze, with the
option -sources or the option -sources-list-file. If the extension of a file
specified by the user is not a valid extension (*.(c|C)), Polyspace Code Prover must
display a warning and continue the analysis without this file.
 Using -sources : list of source files to be analyzed is delimited by double-quotes and
files are separated by a space (Linux®1 and Solaris®) or commas (Windows®, Linux, and
Solaris)
-sources “file1[ file2[ ...]]”
-sources “file1[,[file2[,...]]]”
 Using -sources-list-file: each file name needs to be given with an absolute

path. The syntax of the file is one file by line or many files by line, separated by commas.
 If a file specified by the user does not exist, Polyspace Code Prover must display a
warning and continue the analysis.
 If a file of the source list is a link to another file, the link is not resolved and Polyspace
Code Prover uses the link as source file.
 If no file can be selected, Polyspace Code Prover must stop the execution and display an
error message.
1 Linux is a registered trademark of Linus Torvalds.
2-2
 By default, if the option -sources and the option -sources-list-file are not
specified, source files with the extension *.(c|C)in the directory sources are
selected. This directory sources must be in the current directory. If Polyspace Code
Prover does not find a file respecting the criterion, Polyspace Code Prover must stop the
execution and display an error message.
 Polyspace Code Prover displays an error message and stops if a source file name contains
one of the following characters: ^ ? # ; " ' & ( ) < > = , \ : | §, or non
ASCII characters and ASCII characters with ASCII code not in [32,127].
 Polyspace Code Prover must stop the execution and display a compilation error when
using the following identifiers in source code: unix, i386, asm.
OR-354: Polyspace Code Prover shall accept C language dialects

 Polyspace Code Prover can accept compiler-specific C language dialects with syntactic
or/and semantical extension with the option -dialect.
 The possible arguments of the option -dialect are keil, iar.
 The option -dialect is incompatible with -strict.
 Combined with -dialect, the additional option -sfr-types allows users to specify
their own sfr types name and size
-sfr-types sfr_type_name=sfr_type_size[,...]
where sfr_type_name is a sfr type name and sfr_type_size is its width in number of bits.
Example: -sfr-types sfr=8,sfr16=16
A sfr type size must be 8, 16 or 32 bits.
See Keil & IAR Extensions.
OR-351: Polyspace Code Prover shall accept source files that come from a DOS or
Windows file system
 Polyspace Code Prover can accept source files that come from a DOS or Windows file
system with the option -dos. Polyspace Code Prover must handle upper and lower case
sensitivity in include file names and control characters issues.
2-3
OR-344: Polyspace Code Prover shall allow users to specify the operating system
target
 Polyspace Code Prover allows users to specify its operating system target with the option
-OS-target.
 The known operating system targets are Solaris, Linux, VxWorks, Visual,
and no_predefined_OS.
 If none is specified, the default value depends on the OS of the machine that the
verification is running on. If the verification is performed on a Linux OS, -OS-target
default value is “Linux”. If the verification is performed on a Windows machine, -OS-
target default value is “Visual”. The given operating system target must correspond
to the given include directories, as the target indicates to Polyspace Code Prover what set
of defines is to be used when preprocessing the include directories. If the given include
directories do not correspond to the given operating system, Polyspace Code Prover
displays a warning.
OR-300: Polyspace Code Prover shall provide strict or permissive analysis modes
 Polyspace Code Prover can run in three main modes: default, strict, and permissive.
 The default mode analyzes source files which are compliant with the applicable language
standard (e.g. C90 ISO for C) or use extensions of the standard (for example, in C,
Polyspace Code Prover will accept more bitfield types than those defined in the C90 ISO
standard) and detect run-time errors.
 The permissive mode gives some results quickly, but with a simple model that may not
find all the possible run-time errors. This mode will analyze source files that use
extensions of the standard (for example, in C, Polyspace Code Prover will accept more
bitfield types than those defined in the C90 ISO standard). This permissive mode is
activated by the option -permissive.
- permissive mode =-ignore-constant-overflows + -allow-
negative-operand-in-shift.
 The strict mode gives some results as close as possible to the execution. This strict mode
is activated by the option -strict.
- strict mode = -no-automatic-stubbing + -Wall
 -permissive and -strict options cannot be used together, nor with options
implied by -strict mode.
2-4
OR-375: Polyspace Code Prover shall analyze several files
 Polyspace Code Prover can perform contextual analysis of files separately. In this mode,
each file will be analyzed separately from the others.
 This mode is activated by the option -unit-by-unit. It is available only in
client/server mode.
 If a file contains a function call without declaration of the corresponding function, and if
Polyspace Code Prover cannot deduce the function prototype from the call contexts to
accomplish the permissive stubbing task, the file will not be analyzed (Polyspace Code
Prover will stop on a link failure).
 Some files can be analyzed with every unit (for example, libraries). Those files will be
given to Polyspace Code Prover with the option -unit-by-unit-common-files.
OR-383: Polyspace Code Prover shall check custom rules

See Section 2.1.1 in Polyspace Bug Finder Tool Operational Requirements.
OR-386: Polyspace Code Prover shall check MISRA AC AGC rules

OR-384: Polyspace Code Prover shall pursue verification even if some source files
failed to compile
 Polyspace Code Prover verification can pursue even if some source files does not
compile with the option -continue-with-compile-error.
 At least one file needs to compile in order to pursue the verification
 If stubber or link error occurs, the verification stops.
OR-302: Polyspace Code Prover shall accept bitfields of other types than
signed/unsigned int
 Polyspace Code Prover accepts bitfields of signed int type and unsigned int
type according to the ISO C90 standard.
 Bitfields of other integral types are also allowed.
OR-365: Polyspace Code Prover shall accept unnamed structs fields and unnamed
unions fields
 Polyspace Code Prover can accept unnamed structs fields and unnamed unions fields.
Example 1:
struct {
union {int x; int y; };
2-5
union {int z; int w; };
}s;
s.x ; s.w; /* Warning: non-ANSI unnamed struct/union field */
Example 2:
typedef struct {
struct{int a; int b; };
struct{int a; int c; }; /* Warning: conflicting field named
‘a’ */
}st;
st s = {0, 1, 2, 3 };
s.x ; s.w;
assert(s.a == 0); /* assert green */
assert(s.b == 1); /* assert green */
assert(s.c == 3); /* assert green */
assert(offsetof(st,a) == 0); /* assert green */
OR-303: Polyspace Code Prover shall continue in case of linking errors due to
undefined global variables
 Polyspace Code Prover can continue the execution on undefined global variables.
Polyspace Code Prover supposes that the undefined global variables are initialized and
that the values during the first reading are random.
 If an undefined global variable is volatile, Polyspace Code Prover supposes that the
variable is initialized and each reading has a random value.
OR-304: Polyspace Code Prover shall continue with a shift operation on a negative
number
 The ISO C90 standard says that a left shift has an undefined behavior when used with a
negative left operand. By default, Polyspace Code Prover puts a red check on that
instruction.
 Polyspace Code Prover can accept such an instruction with the option -allow-
negative-operand-in-shift. The check is orange. The result of the instruction,
being implementation-dependent, covers the full range of values of the corresponding
type.
OR-305: Polyspace Code Prover shall ignore default initializations

 By default, Polyspace Code Prover initializes global and static variables to the value 0, as
specified by the C standard.
 Polyspace Code Prover must ignore this default initialization and assume that global and
static variables are not initialized (similar to automatic variables) if it is requested by the
user with the option -no-def-init-glob.
2-6
OR-306: Polyspace Code Prover shall be permissive with overflowing computations on
constants
 Polyspace Code Prover detects overflows on signed integral types constants and
displays an error when the value is out of the range of the specified integral type.
 In accordance with the ISO C90 standard, Polyspace Code Prover does not detect
overflows on unsigned integral type constants and the result value is obtained by
applying the modulus one plus the maximum value which can be represented in the
result.
 Polyspace Code Prover must ignore overflows on signed integral types constants if it is
specified by the user with the option -ignore-constant-overflows. The result
value of the constant expression is obtained by applying the modulus one plus than the
maximum value which can be represented in the result (with sign extension).
 -ignore-constant-overflows cannot be used with -strict mode.
OR-307: Polyspace Code Prover shall be more or less restrictive on overflowing

computations on signed and unsigned integers
 By default, in accordance with the ISO C90 standard, Polyspace Code Prover does not
detect overflows in expressions and sub-expressions of unsigned integral types but detect
overflows in expressions and sub-expressions of signed integral types. This corresponds
to the option -scalar-overflows-checks signed.
 Polyspace Code Prover can detect overflows in expressions (constant or not) and sub-
expressions of signed and unsigned integral types when it is requested by the user with
the option -scalar-overflows-checks signed-and-unsigned.
 Polyspace Code Prover can skip detection of overflows in expressions (constant or not)
and sub-expressions of signed or unsigned integral types when it is requested by the user
with the option -scalar-overflows-checks none. When computation of
expressions or sub-expression overflows without detection by Polyspace Code Prover,
the verification carries on with the value calculated through modulus computation.
 By default, when Polyspace Code Prover detects overflows on an expression or a sub-
expression, the verification carries on with restricted values: the values that avoid the
overflows to occur. This corresponds to the option -scalar-overflows-
behavior truncate-on-error.
OR-308: Polyspace Code Prover shall enable access to a pointer relative to the address
of a field
 This requirement enables access to a pointer relative to the address of a field within
struct/union object with the option -allow-ptr-arith-on-struct.
2-7
 Using this option sets automatically -size-in-bytes.
 In the default mode, accessing objects via a pointer result of a cast or pointer arithmetic
from the address of fields within a structure causes a red check when the written object is
out of memory bounds hold by the referenced field.
 For example, in the following code:
struct S { char a; int b; } x;
char *ptr = &x.a;
ptr++ ;
*ptr = 1 ;
Default:
ptr = 1; /* red pointer within bounds */
The pointer within bounds check is red at *ptr = 1 because of writing a byte out of
the memory hold by x.a
With the option -allow-ptr-arith-on-struct:

ptr = 1; /* green pointer within bounds */
The check pointer within bounds is green because referencing pointer for writing within a
structure via a field address is allowed while the written object is inside the structure
object (inter-fields and end padding included).
 Example with the option -allow-ptr-arith-on-struct: int main()

{
struct S {
char a;
/* 3 bytes of padding between ‘a’, ‘b’ */
int b;
int c;
char d[3];
unsigned char e:7;
char f;
/* 3 bytes of end padding */
};
struct Nesting_S {
struct S s;
int c;
char buf[8];
int d;
} z;
struct S *ptr0;
2-8
char *ptr;
ptr = &z.s.f;
ptr += 4;
*(int *)ptr = 10; /* access to z.c, Green IDP */
ptr0 = &z.s;
ptr = &ptr0->f;
ptr += 4;
*(int *) ptr = 10; /* access to z.c, Green IDP */

ptr = &z.buf[0];
ptr += 8;
*(int *)ptr = 10; /* access to z.d, Green IDP */
return (0);
}
OR-309: Polyspace Code Prover shall allow incomplete or partial allocation of

structures
 By default, Polyspace Code Prover computes the size of an object as integral multiples of
the size of the pointed to object. A cast from a small structure to a larger one will lead to
a red check when dereferencing the latter, because the larger structure is then only
partially allocated.
 Polyspace Code Prover can allow partial allocation through casts of pointers with the
option -size-in-bytes. Dereferencing the pointer to the big structure will lead to
green checks for the allocated fields and red checks for the non-allocated fields.
 For example:
typedef struct _little { int a; int b; } LITTLE;
typedef struct _big {int a; int b; int c;} BIG;
BIG *p = malloc(sizeof(LITTLE));
Default:
p->a = 0; // red pointer out of its bounds
or p->b = 0; // red pointer out of its bounds
or p->c = 0; // red pointer out of its bounds
With the option -size-in-bytes

if (p != ((void *) 0) ) {
p->a = 0; // green pointer within bounds
or p->b = 0; // green pointer within bounds
2-9
or p->c = 0; // red pointer out of its bounds
}
 This behavior is only interesting on source codes that make pointer arithmetic to access
fields of structures. In this case, the goal is to have a better model of the source code, but
the precision is decreased.
OR-310: Polyspace Code Prover shall discard assembler code

 Polyspace Code Prover ignores the assembler code by assuming that the assembler code
does not have side effects on globals.
 Delimiters for assembler code to ignore are given by the user with the options -asm-
begin and -asm-end or can be recognized by Polyspace Code Prover (ISO 90
standard specified asm call and some most commonly implemented asm call syntax).
 -asm-begin and -asm-end must be used together.
OR-313: Polyspace Code Prover shall accept a subset of common C language

extensions and keywords
 Polyspace Code Prover can accept a subset of extensions of C language defined by C99
standard or supported by some popular compilers as gcc.
 Polyspace Code Prover also ignores the following keywords: __thread, restrict, near, far,
rom and __attribute__()
The following extensions are supported:
- designated initializers (labeling initialized elements)

- compound literals (structs or arrays as values)
- boolean type (_Bool)
- statement expressions (statements and declarations inside expressions)
- type of constructs
- case ranges
- empty structures
- cast to union
- local labels (__label__)
- hexadecimal floating-point constants
- extended keywords, operators, and identifiers
(_Pragma, __func__, __const__, __asm__)
2-10
OR-314: Polyspace Code Prover shall ignore missing headers
 Polyspace Code Prover issues a warning instead of an error when some headers are
missing.
OR-408: Polyspace Code Prover shall detect overflows on bitwise-not assignments

 In default mode, overflows are not checked on bitwise-not assignments like:
x = ~ y;
With x and y expressions of the same integral type (signed/unsigned char/short). These
overflows are due to integral promotion.
 These overflows can be detected using option -detect-overflows-on-
operator-not.
OR-391: Polyspace Code Prover shall allow users to model the behavior of the division
 The ISO C90 standard says that if either operand [of / or mod] is
negative, whether the result of the / operator is the
largest integer <= to the algebraic quotient or the
smallest integer >= to the quotient is implementation
defined, as is the sign of the % operator.
 By default, if either operand [of / or mod] is negative, the result of the / operator is the
smallest integer >= to the algebraic quotient. The result of the % operator is deduced
from
a % b = a – (a / b) * b.
 With the option -div-round-down, if either operand [of / or mod] is negative, the
result of the / operator is the largest integer <= to the algebraic quotient. The result of the
% operator is deduced from a % b = a – (a / b) * b.
int x, y;
x = -5 / 3;
y = -5 % 3;
Default:
x = -1;
y = -2;
With the option -div-round-down:

x = -2;
y = 1;
2-11
OR-392: Polyspace Code Prover shall allow users to model the behavior of signed right
shifts
 The ISO C90 standard specifies that for bitwise right shift operation E1 >> E2, if E1
has a signed type and a negative value, the resulting value is implementation-defined.
The most significant E2 bits may be filled with the sign bit value (one) of E1 or zero, E1
>> E2 gives the arithmetical resulting value by keeping sign bit value in the most
significant E2 bits and the logical resulting value by ignoring the sign.
 By default, C Polyspace Code Prover adopts the arithmetical result.
 With the option -logical-signed-right-shift, C Polyspace Code Prover
adopts the logical result.
X = (-7) >> 1;
Default:
x = -4;
With the option -logical-signed-right-shift:

x = 2147483644; (as (-7U)>>1)
OR-393: Polyspace Code Prover shall allow users to specify enum type representation
 The option -enum-type-definition allows Polyspace Code Prover to use
different base types to represent the enum type depending on the enumerator values and
the argument of this option.
 The possible argument values for the option -enum-type-definition are:
- defined-by-standard (default value): enum types are represented by Polyspace Code
Prover using signed int as base type, as specified by the ISO C90 standard.
- auto-signed-first: Polyspace Code Prover uses the first type that can hold all of the
following enumerator values: signed char, unsigned char, signed short, unsigned
short, signed int, unsigned int, signed long, unsigned long, signed long long,
unsigned long long.
- auto-unsigned-first: Polyspace Code Prover uses the first type that can hold all of
the following enumerator values :
 If the enumerator values are all positive: unsigned char, unsigned short,
unsigned int, unsigned long, unsigned long long.
2-12
 If one or more of the enumerator values are negative: signed char, signed
short, signed int, signed long, signed long long. By default, enum types are
represented by Polyspace Code Prover using signed int as base type, as
specified by the ISO C90 standard
OR-311: Polyspace Code Prover shall allow users to specify the target processor
 Polyspace Code Prover allows users to specify the target processor with the option -
target. By default, the i386 target is chosen.
 Polyspace Code Prover must verify that the target processor is contained in the list
(sparc, m68k, powerpc, i386, c-167, tms320c3x, sharc21x61
(21061 and 21161), necv850, mpc5xx, hc08, hc12, c18, x86_64 and
mcpu). If the target processor given by users with the option -target does not belong
to the list, Polyspace Code Prover must stop the execution and display an error message.
 Polyspace Code Prover must model target processor as follows.
C language sparc c-167 M68k Powerpc (32) i386

char 8, 8 8, 8 8, 8 8, 8 8, 8
short 16, 16 16, 16 16, 16 16, 16 16, 16
int 32, 32 16, 16 32, 32 32, 32 32, 32
short long1 unsupported unsupported unsupported unsupported unsupported
long int 32, 32 32, 32 32, 32 32, 32 32, 32
long long 64, 64 32, 32 64, 64 64, 64 64, 32
float 32, 32 32, 32 32, 32 32, 32 32, 32
double 64, 64 64, 64 64, 64 64, 64 64, 32
long double 128, 64 64, 64 96, 64 96, 64 96, 32
pointer 32, 32 16, 16 32, 32 32, 32 32, 32
bytes order big endian little endian big endian big endian little endian
minimum 8 8 8 8 8
addressable size
char is signed2 true true true false true
array alignment 8 8 8 8 8
minimum
struct alignment 8 8 8 8 8
minimum
ptrdiff_type int int long int int
1
Non-ANSI C type available for some targets only.
2
The default configured sign of plain char (without signed/unsigned) can be overwritten with the option -
default-sign-of-char. Possible values are “signed” and “unsigned”.
2-13
C language tms320c3x sharc21x61 necv850 mpc5xx
tms320c4x (21061 and 21161)
char 32, 32 32, 32 8, 8 8, 8
short 32, 32 32, 32 16, 16 16, 16
int 32, 32 16, 16 32, 32 32, 32
short long unsupported unsupported unsupported unsupported
long int 32, 32 32, 32 32, 32 32, 32
long long 64, 32 64, 32 32, 32 64, 64
float 32, 32 32, 32 32, 32 32, 32
double 32, 32 323 (or 64 default is 32, 32, 32 322, 32
32, 32
long double 40, 32 64, 32 64, 32 32, 32
pointer 32, 32 32, 32 32, 32 32, 32
bytes order little endian little endian little endian big endian
minimum 32 32 8 8
addressable size
char is signed4 true true true true
array alignment 32 32 32 8
minimum
struct alignment 32 32 32 8
minimum
ptrdiff_type int int int int
3
The user can use the option - double-is-64bits to set double as 64 bit.
4
C language hc08 hc12 c18 x86_64

char 8, 8 8, 8 8, 8 8, 8
short 16, 16 16, 16 16, 8 16, 16
int 16, 165 16, 164 16, 8 32, 32
short long unsupported unsupported 24, 8 unsupported
long int 32, 32 32, 32 32, 8 6412, 6411
long long 32, 32 32, 32 32, 8 64, 6411
float 32, 32 32, 32 32, 8 32, 32
double 326, 32 325 32 32, 8 64, 6411
long double 32, 32 32, 32 32, 8 96, 6411
pointer 167, 16 328, 32 8/249, 8 64, 6411
bytes order big endian big endian little endian little endian
minimum 8 8 8 8
addressable size
2-14
C language hc08 hc12 c18 x86_64
10 False True true true
char is signed
array alignment 8 8 8 8
minimum
struct alignment 8 8 8 8
minimum
ptrdiff_type Short int Long int int (or short Long int
long9)
5
The user can use the option - int-is-32bits to set int as 32 bit.
6
The user can use the option - double-is-64bits to set double as 64 bit.
7 Limitations:
a) Pointers (near or far pointer) can have 2 bytes of width physically.

b) Non-ANSI C specified key-words and compiler implementation-dependent pragmas and interrupt
facilities are not tokens into account.
8 Limitations:
a) Pointers (near or far pointer) can have 4 bytes of width physically (even if some bytes are unused).
b) Non-ANSI C specified key-words and compiler implementation-dependent pragmas and interrupt
facilities are not tokens into account.
9
The user can use the option - pointer-is-24bits to change the pointer size.
10
11
The default alignment (64) can be modified with the option - align 32.
12
The user can use the option - long-is-32bits to set long as 32-bit and the default alignment for long is
automatically set to 32 bit.
For the types char, short, int, short long, long int, long long, float,
double, long double and pointer, the size in number of bits and the alignment are
given.
OR-390: Polyspace Code Prover shall allow users to define a new target processor
(generic target)
 Polyspace Code Prover allows users to define its owns target processor 8/16 bit MCPU
(Micro Controller/Processor Unit) with int of 16 bits/32 bits width and
pointer of 16 bits (or 32 bits) depending on short or far addressing mode This kind of
devices may have capacity of floating point computation usually of single precision (float
of 32 bits) or/and double precision (option).
2-15
 The option -target mcpu reconfigure
Micro Controller/Processor target. The default configuration (without any
options) of -target mcpu is:
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 32
long long 32 32
float 32 32
double 32 32
long double 32 32
Pointer 16 16
Plain char is signed
byte order: little endian
 The option -default-sign-of-char [signed¦unsigned] allows user to

specify if the plain char is signed or unsigned char.
 The options -big-endian, -little-endian allow the user to specify the
endianness. These options cannot be set together.
- The endianness defines the byte order within a word (and the word order within a long
word).
- "Big endian" architectures are most significant byte first (MSB) (for example SPARC
and m68k).
- "Little endian" architectures are least significant byte first (LSB) (for example i386).
- For a big endian target, the most significant byte of a short integer (for example
0x00FF) is stored at the first byte (0x00) and the least significant byte (0xFF) at the
second byte.
- For a little endian target, the least significant byte of a short integer (for example
0x00FF) is stored at the first byte (0xFF) and the most significant byte (0x00) at the
second byte.
 The default endianness of a generic target is little-endian.
 The option -char-is-16bits sets the plain, signed/unsigned char size to 16 bits. It is
incompatible with -short-is-8bits and -align 8.
 The option -short-is-8bits represents signed/unsigned short with 8 bits and
without specific alignment.
2-16
 The option -int-is-32bits represents signed/unsigned integer as 32 bit long
int. Its alignment, when it is used as struct member or array component, is set also to 32
bits (see also the option -align).
 The option -pointer-is-32bits represents pointer as 32 bit long int. Its alignment,
when it is used as struct member or array component, is set also to 32 bits (see also the
option -align).
 The target MCPU does not support 64 bit integer except with the option -long-long-
is-64bits. Signed/unsigned long long int is treated as 64 bits integer
with memory alignment of 4 bytes boundary (see also the option -align).
 The option -double-is-64bits represents double as IEEE 754 double precision
float with memory alignment of 4 bytes boundary. This option activates the capacity of
double precision floating computation (the option is available for some targets only).
 -align [32|16¦8] set the largest alignment of all data objects to 4/2/1 byte(s)
(32/16/8 bits) boundary.
- With -align 32, the objects of size greater than 4 bytes, used as struct member or
array component, are aligned at 4 bytes boundary. This is the default value if -align
is not specified.
- With -align 16, the objects of size greater than 2 bytes, used as struct member of
array component, are aligned at 2 bytes boundary individually.
- With -align 8, the objects of size greater than 1 byte, used as struct member or array
component, are aligned at 1 byte boundary, the storage assigned to the arrays and
structures is strictly determined by the size of the individual data objects without
member and end padding.
2-17
 Example of the target HC12
- This target is based on the generic target for micro-controller.
- The options -target mcpu -align 8 -big-endian must be set.
- The characteristics of the target are:
Size Alignment
char 8 8
short 16 8
int 16 8
long 32 8
long long 16 8
float 32 8
double 32 8
long double 32 8
Pointer 16 8
 Example of the target MC68000

- The options -target mcpu -align 16 -short-is-8bits -pointer-is-
32bits -big-endian and -double-is-64bits must be set.
Size Alignment
char 8 8
short 8 8
int 16 16
long 32 16
long long 64 16 (not used)
float 32 16
double 64 16
long double 64 16 (not used)
Pointer 32 16
 Example of the target MC68HC908QT4 (m68hc08, m68hc11, m68hc12 and other 8 bit
targets)
- The option -target mcpu must be set.
2-18
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 32
long long 32 32
float 32 32
double 32 32
long double 32 32
Pointer 16 16
 Example of the target ST 7

- The options -target mcpu -align 16 -default-sign-of-char
unsigned -big-endian must be set.
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 16
long long 32 16
float 32 16
double 32 16
long double 32 16
Pointer 16 16
- The user can also use:
 -default-sign-of-char signed to set the plain char as signed
 -pointer-is-32bits to switch pointer size to 32 bit
 -align 8 to set the alignment maximum to 8 bits
 -little-endian or default to switch to little endian
 Example of the target ST 9
2-19
- The options -target mcpu -align 16 -default-sign-of-char
unsigned -big-endian must be set.
Size Alignment
char 8 8
short 16 8
int 16 8
long 32 8
long long 32 8
float 32 8
double 64 8
long double 64 8
Pointer 32 8
 -default-sign-of-char unsigned to set the plain char as signed
 -int-is-32bits to switch pointer size to 32 bit
 Example of the target Hitachi H8 (H8/300, H8/300L families)
- The options -target mcpu -align 16 -double-is-64bits -big-
endian must be set.
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 16
long long 32 16
float 32 16
double 64 16
long double 64 16
Pointer 16 16
2-20
 -default-sign-of-char unsigned to set the plain char as signed
 Example of the target Hitachi H12 (H8/300H, H8S, H8/Tiny families)
- The options -target mcpu -align 16 -double-is-64bits -pointer-
is-32bits -big-endian must be set.
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 16
long long 32 16
float 32 16
double 64 16
long double 64 16
Pointer 32 16
OR-396: Polyspace Code Prover shall allow users to define global assertions
 The global assertion mechanism needs user-defined assertion clauses. To do it, the user
should include pst_gassert.h in the assertions source file. The assertions file is a
user named C source file.The referenced global variables must be declared, and syntax
errors or missing variables declaration causes the compilation stop.
 The macro Pst_Global_Assert(No, Expr) allows the user to define an assertion
clause, No is a unique identifier and Expr is the assertion condition referencing one or
more globals variables.
2-21
 The macro Pst_Global_Assert_Routine(No, Braced_Statements)
allows the user to define a check block returning an integer (boolean) type with non-zero
(true) value meaning passing the check and zero (false) meaning assertion error. No is a
unique identifier and Braced_Statements is a check block. In the check block,
every global variable will be checked on each modification. The user-defined check
block cannot call other functions; it must not modify other global variables because that
action can lead to assertion recursion.
 Pst_Global_Assert(No, Expr) and Pst_Global_Assert_Routine(No,
return (Expr)) are strictly equivalent.
 For variables of array/struct/union type, the modification of only one element/field
implies that the whole object is modified and therefore triggers global assertions on the
whole array/struct/union and elements/fields.
 When an expression on a volatile variable does not respect
the global assertion, the expression becomes unreachable.
Example:
The file including user-defined assertion clauses:
#include <pst_gassert.h>
union U {
int x;
char y;
};
struct S {
int x;
char y;
};
enum glob_state {
INIT_STAT = 1,
IMMEDIATE_STAT,
FINAL_STAT,
UNKNOWN_STAT
};
extern int gx;

Pst_Global_Assert(0, gx < 5);
extern int tab[12];

Pst_Global_Assert(1, tab[2] < 5);
Pst_Global_Assert_Routine(2,
{int ptr = &tab[3]; return(ptr < 5);});
{int i;
int result = 1;
for(i=0, result && i < 10; i++)
2-22
Result = (tab[I] < 5); return result;});
extern struct S s;
Pst_Global_Assert_Routine(4, {return(s.x >= 0;});
{int ptr = (int )&s ;
return(ptr >= 0)}) ;
{char v = s.y;
return (v >= 0);});
extern union U u;
Pst_Global_Assert_Routine(7, return(u.x >= 0);});
{char *ptr = (char )&u;
return (ptr >= 0 && *ptr <= 100);});
extern enum glob_state *glob_s;

Pst_Global_Assert(9, (*glob_s >= INIT_STAT) &&
(*glob_s <= FINAL_STAT));
The user application code:

#include <assert.h>
int tab[12];
struct S s = {10, (char)13};
/* The global assertion 4 is green */
union U u;
volatile int rd = 1;
int gx ;
enum glob_state local_state = INIT_STAT ;
enum glob_state *glob_s;
extern enum glob_state get_global_state(void);
int main(void)
{
int v = -12 ;
int i ;
int *ptr0, *ptr1, *ptr2 ;
gx = 4 ;
/* Array */
if (rd) {
for (I = 0; I < 10; I++) tab[I] = I;
/* The global assertion 3 is red */
}
if (rd) {
ptr0 = &tab[3];
2-23
*ptr0 = 123;
}
/* Struct */
if (rd) s.x = rd;

/* The global assertion 5 is orange */
if (rd) s.x = 0x12345678;
if (rd) s.y = 4;
if (rd) {
ptr1 = (int *0 &s;
*ptr1 = 13;
/* The global assertion 5 is orange */
}
if (rd) s.y = -4;
/* Union */
if (rd) u.y = ‘A’;
if (rd) {
ptr2 = (int *) &u;
*ptr2 = 13;
}
/* pointer */
if (rd) {
glob_s = &local_state;
assert (*glob_s == INIT_STAT *); /* green */
OR-312: Polyspace Code Prover shall automatically stub some subprograms that have
no definition
 By default, Polyspace Code Prover automatically stubs subprograms which have no
definition, except for the following subprograms:
- Parameters of a function pointer type. The prototype of this function type is incomplete
or also takes a pointer type as parameter. For example:
extern int callback(int (*f)());
extern int callback3(int (*f)(int *));
2-24
 Polyspace Code Prover cannot handle memory allocation functions with the automatic
stubber.
 Polyspace Code Prover can not stub an entry-point
 Polyspace Code Prover cannot stub the main subprogram.
 Polyspace Code Prover does not stub subprograms if it is requested by the user with the
option -no-automatic-stubbing. In this case, if a function does not have a
definition, Polyspace Code Prover stops the execution and displays an error message.
 -no-automatic-stubbing cannot be used with -permissive mode.
 Polyspace Code Prover assumes that subprograms to stub do not access global or static
variables.
 The option -stub-files allow to specify files that contain exclusively manual stubs
for functions. Polyspace Code Prover will consider those files as a pool of stubs, and use
the defined functions only if they are called from the analyzed sources. If a function is
defined both in a stub file and a source file, then Polyspace Code Prover uses the
definition from the source file in the verification without raising link errors. However, if
you also specify the -functions-to-stub option, then Polyspace Code Prover uses
the definition from the stub file for functions specified by the option.
 The option -functions-to-stub allows to specify functions that you want
Polyspace Code Prover to stub. If a function is also present in a file specified by the
option -stub-files, then the Polyspace Code Prover verification uses the definition
provided by that file.
OR-319: Polyspace Code Prover shall automatically stub all subprograms that have no
definition
 Polyspace Code Prover can stub subprograms, including subprograms that have
parameters of a function pointer type. The prototype of this function type can be
incomplete or can also takes a pointer type as parameter.
 If the called function prototype is missing. Polyspace Code Prover tries to derive the
prototypes from the call contexts when they are consistent.
variables.
OR-318: Polyspace Code Prover shall be permissive on link

 Polyspace Code Prover accepts integral-type conflicts on arguments or return of
functions between declarations and definitions. In this case, it has effects only when the
size of conflicting integral type is not greater than int or conflicts occur between a pointer
type and an integral type of same size.
2-25
OR-324: Polyspace Code Prover shall continue the analysis after finding red checks
 Polyspace Code Prover must warn the user about red checks at each level of the analysis,
but must continue as if no error had been found.
 When a red check is found in a branch, the rest of the branch is unreachable but the
analysis can continue in the other branches of the application. This behavior allows the
user to find a lot of red checks with the first analysis. The red checks must be fixed
before the launch of another analysis. A consequence of red checks can be some dead
code.
 Some constant computation may cause compile-time overflows. These overflows are not
translated as checks but as compilation errors that stop the analyses.
OR-326: Polyspace Code Prover shall analyze sources of application without the main
subprogram (main generator)
 Polyspace Code Prover can analyze sources of applications without a main subprogram
with the option -main-generator. Polyspace Code Prover generates a main
subprogram that writes random values into global variables and calls the subprograms of
the program with random arguments.
 By default, only non-static global variables are initialized to random and (static or global)
subprograms without callers are called by the generated main with parameters initialized
to random. In all cases, the constant variables will not be assigned. Function pointers will
be initialized to a generated stub if the prototype is complete. For variables of a
struct/union type, only the fields explicitly used are initialized.
 The options -entry-points, -temporal-exclusions-file, -critical-
section-begin and -critical-section-end cannot be set with the option -
main-generator.
 If the option -main-generator is set and if the sources of the application contain a
main subprogram, there is a warning and the main subprogram is kept.
 Generated main has the following structure:
initialize_params // -variables-written-before-loop
call_init_functions // -functions-called-before-loop
while (random) { // Start of main loop
init_inputs // -variables-written-in-loop
call_step_functions // -functions-called-in-loop
}
call_term_functions // -functions-called-after-loop
Each option is described separately hereafter.
2-26
 The option -main-generator-files-to-ignore allows specifying a list of files
or folders for which defined functions are not called by the automatically generated main.
If folders are specified in this list, files in the folder and its subfolders are ignored by the
main generator.
OR-356: Polyspace Code Prover shall check MISRA-C rules

OR-412: Polyspace Code Prover shall initialize global and public variables with the
main generator
 Polyspace Code Prover allows the user to define the behavior of the main generator for
the initialization of global variables with the -variables-written-before-loop
option. The possible values are:
- none: global variables are not initialized.
- public: only non-static global variables are initialized to random.
- all: all global variables are initialized to random.
- custom=x,y: the list of variables given in parameters are initialized to random.
 The option -variables-written-before-loop must be used with the option -
main-generator.
OR-413: Polyspace Code Prover shall re-initialize global and public variables in the
main loop
the randomization of global variables in the main loop, with the -variables-
written-in-loop option. The possible values are:
- none: global variables are not written.
- public: only non-static global variables are written to random.
- all: all global variables are written to random.
- custom=x,y: the list of variables given in parameters are written to random.
 The option -variables-written-in-loop must be used with the option -main-
generator.
2-27
OR-411: Polyspace Code Prover shall analyze some subprograms for the main
generator
the calls of subprograms with the -functions-called-in-loop option. The
possible values of the option are:
- none: no subprogram is called.
- unused: all (static or non-static) except inlined subprograms that are not statically
called by another subprogram are called with parameters initialized to random. A
subprogram that is only called indirectly (through a variable of a function pointer type)
is always considered as unused.
- all: all functions are called except inlined.
- custom=foo,bar: allows the user to specify a list of subprograms to call.
 The option -functions-called-in-loop must be used with the option -main-
generator.
OR-409: Polyspace Code Prover shall accept prologue subprograms with the main
generator
 With the option -functions-called-before-loop, Polyspace Code Prover
allows the user to specify a list of initialization functions that get called only once on
startup after initialization of global variables.
Example:
-main-generator -functions-called-before-loop
hook_init1,hook_init2
where hook_init1 and hook_init2 are existing functions in the source code
 The option -functions-called-before-loop must be used with the option -
main-generator.
2-28
OR-410: Polyspace Code Prover shall accept epilogue subprograms with the main
generator
 With the option -functions-called-after-loop, Polyspace Code Prover allows
the user to specify a list of finalization functions that get called only once after the main
loop.
Example:
-main-generator -functions-called-after-loop
hook_term1,hook_term2
where hook_term1 and hook_term2 are existing functions in the source code
 The option -functions-called-after-loop must be used with the option -
main-generator.
OR-352: Polyspace Code Prover shall be useable for small applications

 By default, Polyspace Code Prover can analyze sources of application without limits for
a number of assignments and subprograms calls if the license file contains a Polyspace
Server license.
 With the option -desktop, Polyspace Code Prover stops the analysis when there are
more than 2000 assignments and subprogram calls. The assignments are not counted in
the main subprogram. This option will check the license file for the presence of a specific
line identifying the Polyspace Code Prover.
 -desktop implies -main-generator option, except if -main option is specified.
OR-355: Polyspace Code Prover shall initialize variables with user-defined ranges
 Polyspace Code Prover can initialize global or file scope variables with user-defined
ranges by using the -data-range-specifications option.
 The argument for this option is a file name. This file can be either a user-defined file or
the generated template (see OR-405: Polyspace Code Prover shall generate default data
range specifications (DRS)).
 The user-defined file should contain : var_name val_min val_max
[init|permanent|globalassert], formatted as text with "tab" "," (comma), " "
(space) or ";" (semi column) as allowed separators. val_min and val_max could be
replaced by min or max, corresponding to possible min and max values for var.
 The automatically generated template, called Extended DRS, is an XML file editable
with the GUI. It contains the same information as the user-defined format in a structured
way. The complete format syntax is described in Description of the Extended DRS
format.
2-29
 A range may be specified for static variables using the Extended DRS file format.
 To define range values, symbolic values min or max can be used, corresponding to the
possible minimum and maximum values of the variables type. For the enum type, the
symbolic values enum_min and enum_max can be used to designate the minimum and
maximum of the enumeration constants defining the enum type. Values out of
enumerations range or min and max can be used for the backward compatibility. In that
case, enum type is interpreted as int.
 Polyspace Code Prover can force the range of value for a stubbed function return. The
syntax for the user-defined DRS format is:
My_function_bar.return val_min val_max permanent
where return is a reserved word indicating the return of function.
 Polyspace Code Prover can force parameters’ values for user-defined functions called by
the main generator. Ranges specified on user-defined functions not called by the main
generator will be ignored. Polyspace Code Prover can also force stubbed functions to
write into their pointer parameters. Those features are supported only in the Extended
DRS file format.
 Polyspace Code Prover can force parameters’ values for user-defined functions called by
the main generator. Ranges specified on user-defined functions not called by the main
generator will be ignored. Polyspace Code Prover can also force stubbed functions to
write into their pointer parameters. Those features are supported only in the Extended
DRS file format.
 init and globalassert modes can be used on the same variable. The globalassert
range must contain the init range.
Example of user-defined DRS file:
# x Equal to [12;100]. int x=0; is ignored
x 12 100 init
# y volatile variable with subrange [0; 10000]
y 0 10000 permanent
z 0 1 globalassert
w min max permanent #w ranged volatile full-range
v 0 max globalassert #v positive
bar.return -100 100 permanent # function bar returns -100..100
2-30
 Allowed types of variable for this option are:
int permanent assert

int yes yes Yes integers: char, short, int, ...
When the range is given in floating point
form, rounding is applied (*).
enum yes yes Yes Range can be given in integer or floating
point form (rounding is applied)
int yes yes Yes floating types: float, double
float no yes no
volatile yes yes Yes integers or floating types only
struct field yes yes Yes array of (array of …) integers or floating
types only
array no no No array[0], ...
pointer (**) no no No
stubbed function yes no No Value of the pointer, number of allocated
return objects, and initialization of pointed to
objects can be specified.
pointer no yes No Stubbed function returning integral/floats.
Pointers are also supported in the extended
DRS format.
Stubbed function yes no No Pointer parameters can be written in.
Parameter (**)
User-defined yes no No When user-defined function is called by
function arguments main-generator, the range of the generated
argument is specified by the DRS
Userdef function no no No
return
(*) the rounded range covers the original range; (example [-12.1, 345.0001] is rounded to
[-13, 346]); the result is out of range of an integer (it will be ignored).
(**) this variable type is supported only in the Extended DRS file format.
 init mode bypasses the variable initialization to initialize variable with user-defined
range. This mode has no effect after the first write.
 permanent mode sets the variable in its given range, even if it is written with out-
range values.
 globalassert mode is equivalent to global_assert( var>=min &&
var<=max).
2-31
2.1.2 Input Requirements on Code Directives
OR-320: Polyspace Code Prover shall accept included directories
 Polyspace Code Prover accepts a list of UNIX directories to search for included files
with the option -I.
 Polyspace Code Prover must display a warning if an include directory does not exist.
 In C, if -OS-target is not set,
‘%POLYSPACE_C%/Verifier/include/include-gnu’ and
‘%POLYSPACE_C%/Verifier/include/Include-gnu/next’ are set at the end of the -I list
of includes folders.
OR-321: Polyspace Code Prover shall allow users to define a list of macro compiler
flags
 Polyspace Code Prover allows users to define a list of macro compiler flags used during
the C preprocessing phase with the option -D.
 This option can be set several times.
OR-321.1: Polyspace Code Prover shall allow users to undefine a list of macro compiler
flags
 Polyspace Code Prover allows users to undefine a list of macro compiler flags used
during the C preprocessing phase with the option -U.
 This option can be set several times.
OR-322: Polyspace Code Prover shall automatically include files in front of all source
files before preprocessing
 Polyspace Code Prover can automatically include some files in front of given source
files before the preprocessing with the option -include
 The file must exist.
 This option can be set several times
2-32
2.1.3 Input Requirements for Analysis Precision
OR-330: Polyspace Code Prover shall allow users to specify the analysis precision
level
 Polyspace Code Prover allows users to specify the precision level to be used with the
options -O0, -O1,-O2, -O3. More precision leads to a longer analysis time:
- Level 0 (option -O0) corresponds to interval analysis: loops and relations between
variable values are not analyzed precisely.
- Level 1 (option -O1) is strictly more precise than -O0 and adds the ability to reason
more precisely on loops.
more precisely on relations between variables values.
- Level 3 (option -O3) is more precise than -O2, but decreases scaling on large
applications.
 If the user gives a value which does not belong to the list, Polyspace Code Prover stops
the execution and displays an error message.
 Default value is -O2.
OR-331: Polyspace Code Prover shall allow users to specify the verification precision
level
 Several verification phases exist:
- C Source Compliance Checking
 This phase must check the compliance of source code before the phase
Intermediate language.
 Some compilation, linking, MISRA-C and MISRA AC AGC errors can be found
and therefore the analysis is stopped. The errors are displayed in the log file.
- C to Intermediate Language
 This phase must generate some intermediate language.
 Some red checks can be found and therefore the analysis is stopped. If no graphical
result is provided, the errors and their locations are listed at the end of the log file.
 Software Safety analysis level 0 The phase C to Intermediate
language must be done before the phase Software Safety analysis level
0.
2-33
 This phase generates the call graph and the data dictionary before the Software
Safety Analysis Level 1.
 The results can be displayed in the Polyspace environment.
 Software safety analysis level 1+
- The phase Software Safety analysis level 0 must be done before the phase
Software safety analysis level 1.
- The level of an analysis is the depth of analysis. The analysis depth starts with Safety
Analysis 1 and goes up to level 4. Each iteration corresponds to a deeper level of
propagation of calling and called context.
 Polyspace Code Prover generates information on stubs:
 The information is displayed in file __polyspace__stdstubs.c.
 This file contains the standard stubs defined by Polyspace Code Prover.
- Polyspace Code Prover generates information on global variables. For each source file
of the application, Polyspace Code Prover generates checks on initializations of global
variables at the declaration. This information is generated in subprograms
_init_globals. If - global variables of the application are initialized,
_init_globals does not exist.
 The user can launch an analysis to a given verification phase with the option -to. -to
must be set at least on the same verification phase as -from, or to a following phase. The
option -from could not take C Source Compliance Checking as parameter.
 The user can relaunch analysis from a verification phase already performed with the
option -from only if intermediate results have been kept with the option -keep-all-
files.
 By default, the verification phase Software safety analysis is done four times.
The maximum number of iterations is twenty times -to=pass[0-4] or -to=other.
OR-332: Polyspace Code Prover shall allow users to specify the analysis precision on
some modules
 Polyspace Code Prover allows users with the option -modules-precision to specify a
list of modules to be analyzed with precision different from the precision of the other
modules. A module is a file.
 Polyspace Code Prover verifies that each module exists in source code. If not, Polyspace
Code Prover stops the execution and displays an error message.
2-34
some subprograms
 Polyspace Code Prover allows users with the option -context-sensitivity to
specify a list of subprograms to be more precisely analyzed on each call to it in the
program. Each check inside the subprogram is split into several sub-checks depending on
the call context. Therefore, if a check is red for a call to the subprogram and green for
another call to the subprogram, both colors will be displayed.
 Polyspace Code Prover verifies that each subprogram exists in source code. If not,
Polyspace Code Prover stops the execution and displays an error message.
 Polyspace Code Prover can choose automatically the leaves subprograms of the
application to be more precisely analyzed if it is requested by the user with the option -
context-sensitivity-auto.
 The option -context-sensitivity cannot be used with the option -context-
sensitivity-auto.
 Limitations
 File names must not contain the following strings: @cs@ or @c@ when using the -
context-sensitivity or -context-sensitivity-auto option.
OR-333: Polyspace Code Prover shall allow users to specify the precision on inter-
procedural analysis
 Polyspace Code Prover allows users to specify the precision on inter-procedural analysis
with the option -path-sensitivity-delta. The precision of propagation of
calling and called context depends on this option.
 By default, the precision on inter-procedural analysis is 0
OR-334: Polyspace Code Prover shall allow float rounding according to the IEEE-754
standard to be activated or disabled
 Polyspace Code Prover rounds float according to the IEEE-754 standard.
 If it is requested by users with the option -ignore-float-rounding, Polyspace
Code Prover can perform the exact computation without rounding.
 Polyspace Code Prover displays a compilation error if -ignore-float-rounding is
set when a constant expression has a float value.
 With this option, Polyspace Code Prover can generate results which are not compliant
with the actual floating computations performed in the execution environment.
2-35
OR-335: Polyspace Code Prover shall provide absolute address validity checks
 By default, Polyspace Code Prover displays ABS_ADDR checks in orange, because
Polyspace Code Prover has no information about the validity of absolute addresses.
 Option -green-absolute-address-checks specifies that ABS_ADDR checks
should be displayed in green.
OR-336: Polyspace Code Prover shall provide inspection points of defined symbols
 Polyspace Code Prover allows users to obtain information on computed domains of
defined symbols at a particular point of execution flow (within the body of a
subprogram) by inserting #pragma inspection_point x directive (where x is a valid
symbol name).
 The inspected symbol must be of simple types (integral, character, enumerated, fixed
point, or float type). The computed domain is a superset of possible values at the
underlying point of the execution flow.
 The inserted #pragma inspection_point directive should be placed as a statement, for
example:
volatile int rd;
int x = rd;
int y = rd;
if (x > 0)
{
/* sample code */
}
else
{
#pragma inspection_point x
;
}
OR-357: Polyspace Code Prover shall retype variables of pointer types in order to
improve precision of pointer
 When a symbol of pointer type aliases to a single type of objects, Polyspace Code Prover
can replace its original type by the aliased object type.
 The -retype-pointer option retypes variables of pointer types to improve
precision of pointer conversions chain, for example:
struct A {int a; char b;} s = {1, 2};
char *tmp = (char *)&s;
struct A *pa = (struct A *)tmp;
assert((pa->a == 1) && (pa->b == 2));
2-36
This principle can be applied to fields of struct/union of a pointer type, for example:
struct S {
int x;
int y;
int z;
char t;
} s = {1, 2, 3, 4};
struct S2 {
int first;
void *p;
} s2, *ptr = &s2;
...
ptr->p = (void *)&s;
assert(((struct S *)ptr->p)->y == 2);
- This option implies -size-in-byte.

- This option is forbidden when -retype-int-pointer is set.
 The -retype-int-pointer option is the same as -retype-pointer. The retyping is
performed on symbols of signed or unsigned integer types having the same size as the
pointer type.
- This option has no effect on global symbols of integer types if -respect-
types-in-globals is set and if the fields of struct/union of integer types -
respect-types-in-fields is set.
- Some NIV and local NIV checks may be stated as NIP checks with the analysis
results.
- This option is forbidden when -retype-pointer is set.
2.1.4 Input Requirements for Information

OR-341: Polyspace Code Prover shall allow users to provide the name of application
 Polyspace Code Prover allows users to provide the name of the application to analyze
with the option -prog. This information shows up in the Polyspace environment.
 Polyspace Code Prover displays an error message and stops if -prog value contains one
of the following characters : $ ^ ? # ; " ' & ( ) < > = , \ : |
§ , the space character or non-ASCII characters and ASCII characters with ASCII code
not in the range [32,127].
 By default, the name of the application is polyspace.
2-37
OR-345: Polyspace Code Prover shall allow users to specify the results directory
 Polyspace Code Prover allows users to specify the directory in which the results of
analysis will be written with the option -results-dir.
 By default, results are written in the directory in which Polyspace Code Prover is
launched.
 If the results directory cannot be created, Polyspace Code Prover must stop the execution
and display an error message.
OR-346: Polyspace Code Prover shall allow users to provide the name of the author
 Polyspace Code Prover allows users to provide the name of the author of the analysis
with the option -author. This information shows up in the Polyspace environment.
OR-347: Polyspace Code Prover shall allow users to provide an analysis date
 Polyspace Code Prover allows users to provide a date for the analysis with the option -
date. This information shows up in the Polyspace environment.
OR-348: Polyspace Code Prover shall allow users to provide a verification version
identifier for the analyses
 Polyspace Code Prover allows users to give a version identifier for the analysis with the
option -verif-version. This information shows up in the Polyspace environment as
the version.
OR-349: Polyspace Code Prover shall display compilation warnings

 Polyspace Code Prover can display warnings during the compilation phase for improper
declarations or statements if they do not cause fatal errors with the option -Wall.
 The default mode does not display warnings.
 -Wall cannot be used with -permissive mode.
2.1.5 Input Requirements for Scaling Options

OR-360: Polyspace Code Prover shall provide the number of consecutive fields of
structures that pointer analysis distinguishes
 By default, pointer analysis distinguishes all fields in complex types.
 Polyspace Code Prover can limit the distinguished depth of types in pointer analysis with
the option -k-limiting.The goal is to help scaling by decreasing precision.
 -k-limiting must be strictly positive.
2-38
OR-361: Polyspace Code Prover shall allow non-pointer global variables to be declared
as not containing pointers
 By default, Polyspace Code Prover considers that a global or static variable can carry
aliases, even if the variable has a non-pointer type.
 Polyspace Code Prover can trust the declared type of the global variables and stop
carrying pointers through those variables with the option -respect-types-in-
globals.The goal is to increase precision and scaling. It makes sense only if the source
code respects this requirement, in accordance with the ISO C standard.
OR-362: Polyspace Code Prover shall allow non-pointer fields of structures to be

declared as not containing pointers
 By default, Polyspace Code Prover considers that a structure can carry aliases in its
fields, even if the fields have a non-pointer type.
 Polyspace Code Prover can trust the declared type of the structures and stop carrying
pointers through their fields with the option -respect-types-in-fields. The goal
is to increase precision and scaling. It makes sense only if the source code respects the
requirement.
OR-363: Polyspace Code Prover shall inline some subprograms

 Polyspace Code Prover can inline some subprograms to distinguish each call with the
option -inline. The goal is to increase precision and scaling. The scaling may be much
better if the given subprograms contain a lot of aliases. The scaling may be worse if the
given subprograms are called too many times and are too large.
OR-364: Polyspace Code Prover shall increase performances on large applications

containing tasks
 With the option -lightweight-thread-model, Polyspace Code Prover can
suppress some readings of shared variables by pointers to increase performances. The
data table is incomplete.
OR-353: Polyspace Code Prover shall analyze applications with large initializations
 With the option -no-fold, Polyspace Code Prover can improve scaling on large
initializations of arrays at the declaration. It approximates initializers of array types of
integral, floating point, and char types (included string), if required.
 This option can decrease the precision but can speed up the analysis.
2-39
OR-374: Polyspace Code Prover shall stop computing and providing range information
on all reads and all operators
 With the option -less-range-information, Polyspace Code Prover can improve
scaling and performance (and also in some cases precision) of the analysis. It stops
computing and providing range and pointer information on read of expressions and on
operators. It gives range information only on assignments of scalars and floats.
on pointers
 With the option -no-pointer-information, Polyspace Code Prover can improve
computing and providing pointer information on read of expressions and on dereference
operators.
 The option -no-pointer-information has no effect if -less-range-
information is already used.
2.1.6 Input Requirements for Tasking

OR-370: Polyspace Code Prover shall allow users to specify a list of tasks
 Polyspace Code Prover allows users to specify a list of tasks/entry points with the option
-entry-points.
 Polyspace Code Prover must verify that subprograms which implement tasks or entry
points exist and do not have parameters. In other cases, Polyspace Code Prover must stop
the execution and display an error message.
 Tasks or entry points are called by Polyspace Code Prover at the end of the main
subprogram (which is executed sequentially) at the same time (the main subprogram
must terminate).
OR-371: Polyspace Code Prover shall allow users to specify some critical sections
through subprograms
 Polyspace Code Prover allows users to specify some critical sections to model the
behavior of binary semaphores or to model protection of shared resources or interruption
masking with options -critical-section-begin and -critical-section-
end.
 Polyspace Code Prover must verify that subprograms which implement critical sections
exist in source code. If not, Polyspace Code Prover must stop the execution and display
an error message.
 This option must be used with -entry-points.
2-40
OR-372: Polyspace Code Prover shall allow users to specify a set of tasks which are
never executed at same time
 Polyspace Code Prover allows users to indicate a set of tasks which are not executed at
the same time with the option -temporal-exclusions-file.
 Polyspace Code Prover must verify that each task exists. If a task does not belong to the
list of entry points, Polyspace Code Prover must stop the execution and display an error
message.
 This option must be used with -entry-points.
2.1.7 Miscellaneous
OR-380: Polyspace Code Prover shall launch a command after preprocessing sources
 Polyspace Code Prover can launch a given script or command after preprocessing, but
before compilation of the source files with the option -post-preprocessing-
command.
 The command or the script must be valid.
OR-382: Polyspace Code Prover shall allow users to filter subprograms that contain
infinite loops
 Polyspace Code Prover allows users to filter out some NTC of subprograms which do not
terminate with the option -known-NTC.
OR-381: Polyspace Code Prover shall allow users to keep temporary files
 At the end of the run, Polyspace Code Prover suppresses all temporary files.
 Polyspace Code Prover can keep these files with the options -keep-all-files. The
option -keep-all-files allows the user to re-launch an analysis from an
intermediate pass.
OR-358: Polyspace Code Prover shall run analysis on supported OS

 Code Prover can run analysis on the following operating systems:
- Windows
- Linux
 OS updates and service packs are supported by Polyspace Code Prover.
 Functional results obtained on supported operating systems must be identical.
 If the OS on which Code Prover is running is not supported, the analysis continues.
2-41
OR-359: Use of Polyspace Code Prover shall be protected by a license mechanism
 Polyspace Code Prover uses two license mechanisms:
- Concurrent license - uses FlexNet® API
- Designated computer license
OR-366: Polyspace Code Prover shall provide remote analysis

 Polyspace Code Prover allows the launching of several analyses launched simultaneously
by several users on their local machines, to be dispatched on several remote machines.
Each remote analysis is split into two separate parts (compilation and analysis) launched
on two different machines (see OPREQS-RL). Some functionalities of remote analysis
can be used in batch mode with Code Prover:
 The option -prepare-remote runs the first part of the remote analysis: the sources
and options verification is performed on the user machine.
- The local analysis stops after pass c-compile.
- A launching command file named relaunching Command.sh is generated in the results
directory to launch the second part of the remote analysis. This launching command
shall be identical to the one used to launch the first part except that the -prepare-
remote option is replaced with -finalize-remote.
- The results of the compilation phase and the newly generated launching command are
compressed and stored in a file named polyspace.tar.gz located in the results directory.
 The option -finalize-remote runs the second part of remote analysis. If the first
part of the remote analysis is completed and without error, the RTE analysis is performed
on the remote machine.
- The remote analysis runs -from c-to-il.
- The analysis can run only with a server license with whatever desktop mode has been
required.
- The results of a remote analysis must be the same as if it were not remotely launched
and results must be compatible with the Polyspace environment.
OR-367: Polyspace Code Prover shall allow users to execute the post analysis
command
 Polyspace Code Prover can execute a command specified by the user once the analysis is
terminated. This command is given as an argument of the option -post-analysis-
command. It is a command/script executable within shell “sh” in the results directory.
 The execution of the given command/script is performed on the machine ending the
remote analysis (client side with -to c-compile, server side otherwise).
2-42
 The given command/script is executed when the analysis ends normally (not killed).
Polyspace Code Prover displays a warning message of the status of the execution (if
performed).
OR-368: Polyspace Code Prover shall generate data for the automatic tests and run
them at the end of the verification
 The option -automatic-orange-tester enables the generation of internal data
required for the automatic tests once the verification results are available, and runs
instrumented tests at the end of the verification during the post verification phase. For the
detailed specification of this feature, see OPREQS-CI.
 The run of automatic tests at the end of the verification can be tuned by the user:
- The option -automatic-orange-tester-timeout <timeout> allows user
to change the timeout (in seconds) set on each instrumented binary execution. The
default timeout is 5 seconds. The value cannot be over 60 seconds.
- The option -automatic-orange-tester-loop-max-iteration <number
of iterations> allows user to change the maximum number of iterations for
loops on each instrumented binary execution. The default value is 1000 loops. The
value cannot be over 1,000 loops.
- The option -automatic-orange-tester-tests-numbers <number of
tests> allows user to change the number of instrumented binary execution. The
default value is 500 runs. The value cannot be over 100,000 runs.
 Polyspace Code Prover display a message concerning the maximum running time for
instrumented tests runs.
 Polyspace Code Prover uses the same seed for instrumented tests runs.
 If a limitation is raised during the code instrumentation after the Code pre-
instrumentation, analysis pursue and a warning is raised.
 Polyspace Code Prover uses instrumented tests results to sort orange checks for the
level0 avaialable in the Polyspace environment.
OR-369: Polyspace Code Prover shall operate on a multi-core OS

 The option -max-processes <number of processes> allows a user to set the
maximum number of processes that may run simultaneously to perform the verification
on a multi-core machine.
 The value of <number of processes> is limited by the number of cores. It cannot
be greater than 128; an error message is displayed otherwise.
2-43
 This option is set by default with the value of argument equal to 4 (e.g. -max-
processes 4).
 To disable the parallelization, even on a multi-core machine, use the option -max-
processes 1.
OR-373: Polyspace Code Prover shall use 32-bit or 64-bit addressing mode
 Polyspace Code Prover provides -machine-architecture <argument> option
to set 32-bit or 64-bit addressing modes on 64-bit machines.
 The possible values of -machine-architecture argument are: 32,64,auto.
 The default configuration is -machine-architecture auto. It activates 32-bit
mode.
OR-385: Polyspace Code Prover shall stop verification after a user defined time amount
 The option -timeout enables user to set a time limit to Polyspace verification.
 The time limit only applies on the server. The time consumed during the client part is not
counted as part of the time limit.
 The possible values of -timeout are HH[,.MM] where HH is an hour amount and MM
is a part of hour amount.
 By default, there is no time limit on Polyspace Code Prover verifications.
OR-376: Polyspace Code Prover shall export a verification report

 Polyspace Code Prover may generate a report that summarizes the verification. The
report is generated at the end of the full verification, before any post analysis command
(if option -post-analysis-command is used).
 Such a report will be generated if option -report-template is used. The option takes
as argument the name of a template file. That template defines what kind of information
will be included in the report and what the overall format will be.
 The format of the report can be HTML, PDF, RTF, Word (not available on UNIX
platform) and XML. The option -report-output-format will define the format of
the report. RTF is the default format.
 The name of the generated report file can be defined. The option -report-output-
name will define the name of the report file. The default report will be named:
“{Prog}_{TemplateName}.{Format}” ({Prog} being defined by -prog,
{TemplateName} being defined by -report-template and {Format} being defined
by -report-output-format).
2-44
OR-394 Polyspace Code Prover shall allow users to import coding rule(s) and runtime
error(s) comments from results folder
 The user can import coding rule(s) and runtime check(s) comment from specified results
folder.
 The option -import-comments allows user to specify the location of a Polyspace
Code Prover results folder.
OR-395 Polyspace Code Prover shall continue verification if only one source file
compiles
 The option –continue-with-compile-error allows user to continue verification

even if only one file compiles. Files that have compilation errors are not verified. The
verificaiton results may not contain all coding rule violations or errors.
2-45
2.2 Output Requirements
2.2.1 Output Requirements for Call Graphs
OR-400: Polyspace Code Prover shall generate call graphs
 Polyspace Code Prover has to generate a call graph if analysis goes up to Software
Safety analysis level 0.
 The call graph has to provide for each function foo:
- The subprograms called by foo with localization of the call (file + line + column) and
the subprogram called (file + line + column).
- The subprograms which call foo with localization of the call (file + line + column) and
the caller (file + line + column).
- The tasks which call foo with localization.
 Calls of the assert function are not given in the call graph.
 The call graph has to be generated in an external format usable (see Description of Call-
Graph File) without the Polyspace environment, and easily exploitable by users.
 The call graph can be different with the option -inline. Each call of inlined
subprograms is distinguished.
2.2.2 Output Requirements for Data Dictionaries

OR-401: Polyspace Code Prover shall generate data tables
 Polyspace Code Prover has to generate a data table if analysis goes up to Software
 The data table has to provide for each global variable bar:
- Accesses (read, write) for bar with their localization (file + line + column). Read and
write accesses are distinguished by the character < and > (< for write access and > for
read access). For structured variables like union and structure, accesses are provided at
field level. Potential accesses might not be distinguished depending on alias analysis
precision. Access occurring in part of the application that is not executed (unreachable
branches, not called functions) is marked as unreachable.
- Potential accesses (read, write) for each de-reference of bar with their localization (file
+ line + column).
2-46
- A range of all the values taken by the variable is provided for scalar variables (i.e.
neither structured variables as union or structure not array variables).
- A summary of bar characteristics as type, range type, range value, and declaration
localization.
- Variables that are not read and not written or for which accesses are unreachable are
marked as unreachable.
- Protection used for bar (critical section, temporal exclusion, and access pattern).
- If bar is a shared variable.
- A summary of concurrent accesses by tasks (read, write).
 Variables declared but not used do not appear in the data table.
 The data table has to be generated in an external format usable (see Description of Data-
Table File) without the Polyspace environment, and easily exploitable by users.
2.2.3 Miscellaneous
OR-402: Polyspace Code Prover shall export run-time checks
 Polyspace Code Prover has to generate run-time checks in an external format usable
without the Polyspace environment, and easily exploitable by users (see Description of
PSCP files) if analysis goes up to Software Safety analysis level 0.
OR-403: Selectivity rate of Polyspace Code Prover results shall not decrease more than
5% between two releases
 Polyspace Code Prover has to provide results with an acceptable selectivity rate. What is
acceptable is strongly linked with the application characteristics and the analysis inputs.
 Polyspace Code Prover has to provide selectivity rates in both alpha and beta modes for
each Software Safety analysis step.
OR-404: Polyspace Code Prover shall export range values

 Polyspace Code Prover has to generate information on computed ranges for simple types
(integral, character, enumerated, fixed point, or float type) and for pointer types. The
computed range is a superset of all possible values taken during the execution. The
information is provided for non-dead reads of expressions, writes of expressions, and
operators.
 The range and pointer information is provided as tooltips in the Polyspace environment.
This information is not available in the textual output.
2-47
 In case of use of the option -less-range-information, only the ranges of the
assignments are computed and exported.
 In case of use of the option -no-pointer-information, information on pointers is
not computed or exported.
OR-405: Polyspace Code Prover shall generate default data range specifications (DRS)
 Polyspace Code Prover automatically generates a template file named “drs-template.xml”
in the result folder for variables, functions, and methods eligible for -data-range-
specifications option. This template can be edited and modified through the data
range specification GUI. It can be re-used as argument of -data-range-
specifications option.
 If a user-defined file has been used with -data-range-specifications option,
information from this file is taken into account in the generated template file.
OR-406: Polyspace Code Prover shall identify sources of imprecision

 Some constructions of the program or the modeling (choice of options) force variables to
be full-range in their type. Then the checks on operations that use the corresponding
variables will be colored orange. Distinguishing those checks allows the user either to
change the code or the modeling, or at least to know a probable cause of the orange
check.
 A message is added to the orange checks to give the possible sources of imprecision.
This message is optional (there may be some sources of imprecision not detected by
Polyspace).
 The sources of imprecision that may be identified are: volatile variable, extern variable,
absolute address, write of a variable by Polyspace main-generator, call of a function by
Polyspace main-generator, or call to a function stubbed by Polyspace automatic stubber.
 Several possible causes of imprecision can be given on a single check.
OR-407: Polyspace Code Prover shall generate source code metrics

See Section 2.2 in Polyspace Bug Finder Tool Operational Requirements.
2-48
2.3 Performance Requirements
2.3.1 Polyspace Code Prover Time Increase Threshold
OR-802: Elapsed time to execute Polyspace Code Prover shall be less than an absolute
time for six applications of BTV
 Polyspace Code Prover has to generate results in time less than an absolute time for three
real applications of the BTV. The time is given for an execution of Polyspace Code
Prover on a Red Hat® 7.2 machine with the following configuration:
- CPU Intel PentiumIV >= 1.5GHz
- RAM >= 1GB
- SWAP >= 2.8GB
Absolute Time Precision Level Verification Phase Number of Lines

LPLG-O0 15h O0 Safety Analysis 4 85619
SRS-O2 13h O2 Safety Analysis 2 195382
MJRS-O0 13h O0 Safety Analysis 2 60744
2-49
2.4 Language-Specific Requirements
For each language-specific version of Polyspace Code Prover, there is a required construct,
semantic support level. There are four such levels: SSL1 ... SSL4. The lowest level, SSL4,
means that the program construct is accepted by Polyspace Code Prover but without any
guarantee of the soundness of its analysis, while the highest level, SSL1, requires Polyspace
Code Prover to fully handle the construct. Full support means that it is accepted syntactically,
processed semantically in a sound manner with respect to the applicable semantic model, and
also, from the point of view of the errors, generated directly. The following table summarizes
the four semantic support levels.
Table 1 Semantic Support Levels

Level Construct Effect of construct fully Checks associated to construct
syntactically modeled according to the generated according to the
accepted semantic model, including semantic model
return value
SSL1 Yes Yes Yes
SSL2 Yes Yes No
SSL3 No11 No No
SSL4 Yes No No
11
SSL3 support requires detection and rejection of the corresponding construct.
A common requirement will be that floating overflows and domain errors are halting the
execution of the subject program. In IEEE-748 terms, it is assumed that the generation of a NaN
or of infinity halts the computation. This implies that a multiplication that overflows shall be
detected by Polyspace Code Prover as an error (with a corresponding orange or red check). This
corresponds in the IEEE-748 model to setting the exception generation on overflow. This differs
from the ANSI/ISO semantic model for C (for instance) which is compatible with the generation
of IEEE-748 special values such as infinity and NaN, instead of the generation of exceptions.
Polyspace Code Prover can therefore be stricter than the language standard as regards floating
point exceptional conditions. This is however, acceptable as Polyspace Code Prover will thereby
signal floating errors according to the strictest semantics.
To summarize, Polyspace Code Prover assumes that floating point overflows are undesirable
run-time errors.
2-50
2.4.1 Semantic Requirements
LSR-300: Semantic Reference Model for C Polyspace Code Prover
The applicable language standard for Polyspace Code Prover is the International standard
ISO/EIC 9899: 1990 (E), often informally referred to as C90 or ANSI C90, complemented with
the floating point IEEE-748 model and the following specificities:
 Floating overflows and domain errors are errors halting the execution of the C program.
In IEEE-748 terms, the generation of a NaN or of an infinity halts the computation.
 Subprogram parameters are evaluated from left to right.
 No pointers are stored in objects of floating or enumerated type, then read from these
objects and subsequently dereferenced.
 Some local-specific multi-byte character sets can be recognized in the source code by
default or with option. The list of character sets recognized by default is Shift-JIS, EUC-
JP, ISO-2022-JP, UTF-8.
LSR-301: Semantic Support Levels for C Polyspace Code Prover

All C ANSI/ISO constructs as specified in LSR-300 shall be supported at level SSL2 or SSL1
with the exception of the following constructs:
 LSR-301-1 backwards goto statements and a goto from the outside of a loop to one the
inner instruction shall have SSL3 support.
 LSR-301-2 threads/tasks with parameters shall have SSL3 support.
 LSR-301-4 global/static arrays, strings, unions or structs greater than 128 Mb shall have
SSL3 support.
 LSR-301-5 varargs functions without prototype shall have SSL3 support.
 LSR-301-6 the library functions setjmp(), longjmp(), signal(), raise() and
free() shall have SSL4 support.
 LSR-301-7 dynamic task/thread creation shall have SSL4 support.
 LSR-301-8 dynamic construction of functions shall have SSL4 support.
 LSR-301-9 implicit aliasing using absolute addresses shall have SSL4 support.
 LSR-301-10 arithmetic on function pointers shall have SSL4 support.
 LSR-301-11 a function which returns a pointer to a local variable shall have SSL4
support.
2-51
 With LSR-301-12, the following functions cannot be redefined as they are hard-coded in
Polyspace Code Prover:
- malloc, calloc, realloc, valloc, alloca, __builtin_alloca
 LSR-301-13 Compatible structure passed in arg of old KandR function style generates a
compilation error, due to Polyspace Code Prover being stricter during
compilation than other compilers.
 LSR-301-14 Flexible size array shall have SSL4 support.
 LSR-301-15 Arguments of printf-like standard functions shall have SSL2 support.
 LSR-301-16 Header and source file names with non-ASCII characters shall have SSL3
support.
 LSR-301-17 Absolute addresses containing objects of pointer types shall have SSL4
support.
 LSR-301-18 Non-initialized source memory area in the memory copy and move routines
(memcpy, memmove) shall have SSL4 support.
 LSR-301-19 An invalid pointer is considered equal to a null pointer.
 LSR-301-20 Taking the address of critical section routines shall have SSL3 support.
 LSR-301-21 Nested block of depth greater than 1000 shall have SSL3 support.
 LST-301-22 Call to the main program or routines defined as entry point shall have SSL3
support.
2.4.2 Applicable Checks for C Polyspace Code Prover

LSR-303: Applicable checks for C Polyspace Code Prover
Polyspace Code Prover shall generate checks according to Table 2: Semantic Checks, with the
Semantic Support Levels as described in Table 1: Semantic Support Levels. Most language
constructs have level SSL1, while language libraries typically have level SSL2.
 Polyspace Code Prover is allowed to avoid generating a check if the corresponding

operation involves only constants and the check can be trivially determined as correct
(green) by constant folding.
 Polyspace Code Prover shall generate checks for assertions given by assert(pred) whose
dynamic semantics is to halt the computation if the predicate pred evaluates to false.
2-52
Table 2 Semantic Checks
Req ISO/IEC Description in ISO/IEC Details Typical run-time SSL
9899:1990 9899:1990 consequences
Sections
LSR-303-1 6.2.1.2, G.2 An arithmetic conversion produces Conversions to unsigned integral Compilers implement modulo SSL1
(p. 200) a result that cannot be represented types, or from unsigned integral semantics in all cases: erroneous
in the space provided, subcase 1: types to signed integral types of a computations may ensue.
integral types same width have modulo semantics.
Conversions from unsigned integral
types to smaller signed integral
types, and conversions from signed
integral types to smaller signed
integral types are subject to
over/underflow checking.
LSR-303-2 6.2.1.3, G.2 An arithmetic conversion produces Conversions from float/double to Compilers generate code which SSL1
(p. 200) a result that cannot be represented integers are subject to either saturates or generates an
in the space provided, subcase 2: under/overflow checking. exception.
floating and integral conversions
LSR-303-3 6.2.1.4, G.2 An arithmetic conversion produces Conversions from double to float are Compilers generate code which SSL1
(p. 200) a result that cannot be represented subject to under/overflow checking. either saturates or generates an
in the space provided, subcase 3: exception.
floating conversions
LSR-303-4 6.3, G.2 An arithmetic operation is invalid Only operands of signed types are Compilers generate exceptions on SSL1
(p. 200) (such as division or modulus by 0) subject to overflow checking invalid operations and modulo
or produces a result that cannot be (including +, -, /,* on integral and semantics on overflows.
represented in the space provided floating types) as Section 6.1.2.5 of
(such are overflow or underflow) ISO standard (p. 23) stipulates that
"A computation involving unsigned
operands can never overflow".
LSR-303-5 6.3.2.2, G.2 For a function call without a Includes calls via function pointers Compilers generate code which SSL1
(p. 200) function prototype, the number of may crash at runtime.
arguments does not agree with the
number of parameters.
LSR-303-6 6.3.2.2, G.2 For a function call without a Includes calls via function pointers Compilers generate code which SSL1
(p. 201) function prototype, if the function may crash at runtime.
is defined without a function
prototype, and the types
of the arguments after promotion
do not agree with those of the
parameters after promotion.
LSR-303-7 6.3.2.2, G.2 If a function is called with a Includes calls via function pointers Compilers generate code which SSL1
(p. 201) function prototype and the function may crash at runtime.
is not defined with a compatible
type.
LSR-303-8 6.3.2.2, G.2 A function that accepts a variable Includes calls via function pointers Compilers generate code which SSL1
(p. 201) number of arguments is called may crash at runtime.
without a function prototype that
ends with an ellipsis.
2-53
9899:1990 9899:1990 consequences
Sections
LSR-303-9 6.3.4, G.2 A pointer to a function is converted This error is not detected at compile Compilers generate code which SSL1
(p. 201) to point to a function of a different time by classical compilers. may crash at runtime.
type and used to call a function of a
type not compatible with the
original type.
LSR-303-10 6.3.4, G.2 A pointer to a function is converted Reading through the object pointer Compilers generate code which SSL1
(p. 201) to a pointer to an object. is correct within the function's may crash at runtime: either at
bounds and incorrect outside. write time (because there is a page
Writing through the object pointer is protection scheme, MMU, …) or at
an error. function call time.
LSR-303-11 6.3.4, G.2 A pointer to an object is converted Calling the corresponding function Compilers generate code which SSL1
(p. 201) to a pointer to a function. pointer is an error. may crash at runtime.
LSR-303-12 6.3.6, G.2 A pointer that does not behave like Polyspace Code Prover shall detect Memory corruption, unpredictable SSL1
(p. 201) a pointer to an element of an array such errors at the time of behavior, or crash.
object is added to or substracted dereference only. Consequently, the
from. expression ((&x)+1)-1 shall be
deemed correct, but the following
dereference shall be identified as an
error: int x=1; int *t=&x; t[4] = …;
LSR-303-13 6.3.6 Unless … the result points to an Polyspace Code Prover shall detect Memory corruption, unpredictable SSL1
element of the same array object, such out-of-bounds accesses on top- behavior, or crash.
the behavior is undefined if the level arrays, arrays contained in data
result is used as an operand of the structures and dynamically allocated
unary * operator objects. For instance accessing
a[0][5] given the declaration int
a[4][5]; or dereferencing a null
pointer shall be detected as an error.
LSR-303-14 6.3.7, G.2 An expression is shifted by a In the second case it amounts to a Compilers generate code which SSL1
(p. 201) negative number or by an amount form of overflow. returns zero in the first case and
greater than or equal to the width which implements the identity in
in bits of the expression. the second case.
LSR-303-15 6.5.7, G.2 The value of an uninitialized object This is the non-initialized variable Compilers generate code which SSL1
(p. 201) that has automatic storage duration problem. will behave randomly at runtime as
is used before a value is assigned. automatic (stack) objects are not
initialized to zero.
LSR-303-16 NA The value of the object allocated This is the non-initialized variable Implementations of malloc do not SSL1
by the malloc() function is used problem in the case of dynamically initialize the memory blocks.
before a value is assigned allocated objects Unpredicatable behavior can ensue.
LSR-303-17 6.6.6.4, G.2 The value of a function is used, but This is the non-initialized return Compilers generate code which SSL1
(p. 201) no value was returned. value problem. Polyspace Code will behave randomly at runtime as
Prover shall implement this by the space used for returning values
checking that functions declared as (a register, a stack location …) is
returning non-void objects do return not cleared for efficiency reasons.
a value.
LSR-303-18 7.1.7, 7.2, 7.3, A library function argument has an Includes null pointers and out-of- Memory corruption, unpredictable SSL2
7.4, 7.5, 7.6, invalid value, sub case: pointer bounds pointers passed to frexp(), behavior or crash often occurs
7.7, 7.8, 7.9, arguments. modf() and to all other functions of when these functions are applied to
7.10, 7.11, Sections 7.2 to 7.12 with pointer out-of-bounds or null pointers.
7.12, G.2 parameters (stdio.h, stdlib.h,
(p. 202) string.h, time.h, …)
2-54
9899:1990 9899:1990 consequences
Sections
LSR-303-19 7.2.1.1 The assert(int expr) macro This is a debugging and testing Used during tests and disabled in SSL1
puts diagnostics into programs. facility for which Polyspace Code production.
When it is executed, if expr Prover shall generate a check
evaluates to false (…) then the indicating the failure status of the
assert macro writes information corresponding assertion. It can also
about the particular call that failed be used to: (1) ask Polyspace Code
(…) it then calls abort. Prover to prove that a particular
property is always true; (2) assume
that a particular property holds (in
particular to take into account
system-level properties).
LSR-303-20 7.3 An argument to a character- Example erroneous call: Memory corruption, unpredictable SSL2
handling function is out of the isalpha(0xfffff) behavior, or crash often occurs
domain (ctype.h) when these functions are applied to
values outside the range of EOF,
0..UCHAR_MAX
LSR-303-21 7.4 The locale.h library. No checks and undefined behavior, SSL2
besides those described in LSR-303-
18
LSR-303-22 7.5 For all functions, a domain error Relavant functions: acos(), In implementations, an IEEE748 SSL2
occurs if an input argument is asin(), atan2(), log(), log10(), NaN or exception will be
outside the domain over which the pow(), sqrt(), fmod(). Semantic generated.
mathematical function is defined. model required: exception
generation on domain error.
LSR-303-23 7.5 A range error occurs if the result Relevant functions: tan(), cosh(), In implementations, an IEEE748 SSL2
of the [mathematical] function sinh(), exp(), ldexp(), log(), infinity or overflow exception will
cannot be represented as a pow(). Semantic model required: be generated.
double. exception generation on range error
instead of infinity (HUGE_VAL)
generation.
LSR-303-24 7.6 Non-local jumps: the setjmp() Required Polyspace Code Prover SSL4
and longjmp() functions. support: assume that these functions
have no effect.
LSR-303-25 7.7 The signal() and raise() Required Polyspace Code Prover SSL4
functions. support: assume that these functions
have no effect.
LSR-303-26 7.8 The varargs.h library. SSL2
LSR-303-27 7.9 The stdio.h library. SSL2
LSR-303-28 7.10 The stdlib.h library. SSL2
LSR-303-29 7.11 The string.h library. SSL2
LSR-303-30 7.12 The time.h library. SSL2
2-55
2.5 Traceability Matrix HLR/OR and LSR
For traceability between the High-Level Requirements (HLRs), Operational Requirements

(ORs) and Language Specific Requirements (LSRs), see:
2-56
2.6 Polyspace Products for C Appendixes
2.6.1 Description of Call-Graph File
2.6.1.1 File Description
This multi-line text file is constructed as follows:
The first line contains the legend of fields used by data table (described in the next section).
The call tree description begins with the main subprogram, and follows lines that reproduce
Call-Tree.
The function calls are displayed from main in the same order as in the application.
Depth of call is given by the number of | characters before the > or -> symbols (for example |
| | -> means a depth of 3 calls from the main function) . Differences between terminal
calls (subprograms that do not call subprograms) and non-terminal calls are indicated by > for
terminal calls and -> for the others.
Particular cases of indirect recursion calls are printed as follows: | | … | **

RecursiveCall: which indicates the other function of the indirect recursion.
The line fields are separated by a tabulation character (\t UNIX code). For field descriptions,
see Section 2.6.1.2.
When a function calls a function that has already been called, the corresponding call-graph part
is not repeated. Instead, only a message already displayed above is printed.
This file is generated by the gen-excel-file script.
2-57
2.6.1.2 Fields Description
Call tree:
Contains the name of the called function, the depth of the function call from the main, and the
case of terminating or non-terminating call.
The format is :
| | | … | - > [package|file].FunctionName
or
| | | … | ** RecursiveCall: [package|file].FunctionName
Appears in each line representing a call.
File:
Contains the localization (file name) of a function call.
Line:
Contains the localization (line number) of a function call.
This field appears in each line representing a call.
Col:
Contains the localization (column number) of a function call.
2-58
2.6.1.3 Example
Here is an example of a call tree in Excel file format from the tests set application.
2-59
2.6.2 Description of Data-Table File
2.6.2.1 File description
The first line contains the legend of fields used by data table (described in the next section). The
second line contains only the application name, and this line starts with a “-“.
The data table opens:
For each global variable, one line containing its characteristics (type, value, …) is printed.
Further on in this document, this line will be called CL (characteristics line). These lines begin
with a pattern of the form | - or like | | | … | - for sub-fields of global
variables.
If the global variable is read or written, for each access to it an access line (AL) is printed above
the CL. Lines begin with a pattern of the form | < (write access) or
| > (read access), and with a pattern | | … | > (read access) or | | …
| < (write access) for global variables sub-fields.
For each global variable, accesses are sorted by type (read or write, write accesses are printed
first, and then read accesses), and accesses are printed until a new CL is encountered.
To make information easier to extract from this file, fields of both CL and AL are separated by a
tabulation character (\t).
At the end of the data table, an Excel file appears with a section called legend, which links task
acronyms found in field W.T. (like t[0-9]) and tasks obtained by -tasks option.
2.6.2.2 Fields description

Variables:
Contains the name of global variables.
The format is:
[Package|File].VarName[.subfield1 [.subfield2[…]]]
This field appears only in CL and is empty for AL.
2-60
W.T: (written by tasks)
Contains the descriptor of tasks defined by -entry-points which write the global variable
(correspondences between tasks names from -entry-points and tasks descriptor are
available at the end of the Excel file).
The format is:
[t1[,t2[,…]]]
This field is empty if the global variable is not written by a task.
R.T: (read by tasks)

Contains the name of the tasks reading the global variable.
The format is:
[task1[,task2[…]]] where task1, task2 are tasks given as parameters to the
-entry-points option
Protection:
Contains protection(s) used for protection of global shared variables.
Possible values are:
 Critical section – if accesses are protected by critical sections
 Access pattern – if accesses are protected by access patterns
 Temporal exclusion – if accesses are protected by temporal exclusion
 Null – if no protection is applied to the shared variable
The format is:
[Critical section[,…]]
Usage:
Contains usage of global variables.
2-61
 readNOTw – If the variable is read but not written
 aliased – if the variable is aliased
 shared – if the variable is shared by tasks
The format is:
[readNOTw[,aliased[,…]]]
This field is empty if no specific usage is done for global variable.
Scal:
Contains the answer to the question Is the variable a scalar?.
 Yes – if the variable is a scalar one
 Empty – if no information is provided about the variable
The format is:
Line:
Contains the localization (line number) of access to a variable.
This field appears only in AL and is empty for CL.
Col:
Contains the localization (column number) of access to a variable.
File:
Contains the localization (file name) of access to a variable.
Detailed type:
Provides the type definition of the global variable.
This type is the type provided at variable declaration.
2-62
Unreachable:
Provides information for CL and AL if the access or the variable is in unreachable code.
It can be either empty (i.e. executable) or has the “is unreachable” value.
For AL, this field is empty if the access is in executable code. For CL, this field is empty if the
variable has at least one executable access.
Value:
Provides values that a global variable can reach during execution, given as a disjunction of
intervals.
This field is empty if no value was computed by Polyspace Code Prover.
Potential:
Provided the information about potential access (in C only, due to pointer analysis).
 Is potential – if the access is potential
 Empty – if the access is certain
Nb read:
Contains number of read accesses to the global variable.
The format is: [x]
Nb write:
Contains number of write accesses to the global variable.
The format is: [x]
2-63
2.6.2.3 Example
Here is an example of a Data Dictionary in Excel file format from the tests set application.
2.6.3 Fully or Partailly Implemented MISRA-C:2004 Rules

2.6.4 Predefined MISRA-C:2004 Rules Subsets

2.6.5 Fully or Partially Implemented MISRA-C:2012 Coding

Directives and Rules
2.6.6 Predefined MISRA-C:2012 Rules Subsets

2-64
2.6.7 Options-ORs Correspondance
Option Operational Requirement
-align OR-390
-allow-negative-operand-in-shift OR-304
-allow-ptr-arith-on-struct OR-308
-asm-begin OR-310
-asm-end OR-310
-author OR-346
-automatic-orange-tester OR-368
-automatic-orange-tester-loop-max-iteration OR-368
-automatic-orange-tester-tests-number OR-368
-automatic-orange-tester-timeout OR-368
-big-endian OR-390
-context-sensitivity OR-338
-context-sensitivity-auto OR-338
-continue-with-compile-error OR-384
-critical-section-begin OR-371
-critical-section-end OR-371
-D OR-321
-date OR-347
-data-range-specifications OR-355
-default-sign-of-char OR-390, OR-311
-desktop OR-352
-scalar-overflows-check OR-307
-scalar-overflows-behavior OR-307
-dialect OR-354
-div-round-down OR-391
-dos OR-351
-double-is-64bits OR-390
-entry-points OR-370
-enum-type-definition OR-393
-finalize-remote OR-366
-from OR-331
-functions-called-after-loop OR-410
-functions-called-before-loop OR-409
-functions-called-in-loop OR-411
-functions-to-stub OR-312
-green-absolute-address-checks OR-335
-I OR-320
-include OR-322
-int-is-32bits OR-390
-ignore-constant-overflows OR-306
-ignore-float-rounding OR-334
-detect-overflows-on-operator-not OR-408
2-65
-inline OR-363, OR-400
-keep-all-files OR-381
-known-NTC OR-382
-k-limiting OR-360
-lang OR-340
-lightweight-thread-model OR-364
-little-endian OR-390
-less-range-information OR-374
-logical-signed-right-shift OR-392
-long-is-32bits OR-311
-long-long-is-64bits OR-390
-machine-architecture OR-373
-main-generator OR-326, OR-342, OR-412, OR-411, OR-329,
OR-339, OR-410, OR-409, OR-413
-main-generator-files-to-ignore OR-326
-max-processes OR-369
-modules-precision OR-332
-no-automatic-stubbing OR-312, OR-319
-no-def-init-glob OR-305
-no-fold OR-353
-no-pointer-information OR-379
-O0, -O1, -O2, -O3 OR-330
-OS-target OR-344
-path-sensitivity-delta OR-333
-permissive OR-300
-pointer-is-32bits OR-390
-post-analysis-command OR-367
-post-processing-command OR-380
-prepare-remote OR-366
-prog OR-341
-report-template OR-376
-report-output-format OR-376
-report-output-name OR-376
-respect-types-in-fields OR-362
-respect-types-in-globals OR-361
-results-dir OR-345
-retype-int-pointer OR-357
-retype-pointer OR-357
-sfr-types OR-354
-char-is-16bits OR-390
-short-is-8bits OR-390
-size-in-bytes OR-309
-sources OR-343
-sources-list-file OR-343
2-66
-strict OR-300
-target OR-311
-temporal-exclusions-file OR-372
-timeout OR-385
-to OR-331
-U OR-325
-unit-by-unit OR-375
-unit-by-unit-common-source OR-375
-variables-written- before -loop OR-412
-variables-written-in-loop OR-413
-verif-version OR-348
-Wall OR-349
2-67
2.6.8 Keil & IAR Extensions
KEIL Dialect Support
Language Description Example
Extension
1 bit type converting an expression to type bit gives value 1 if the bit x = 0, y = 1, z = 2;
expression is not equal to 0, else 0; it is not a truncation assert(x == 0);
taking only the least significant bit. this behavior is similar to assert(y == 1);
that of the c++ bool type. assert(z == 1);
restrictions: pointers to bits and arrays of bits are not allowed. assert(sizeof(bit) == sizeof(int));
2 special function unsigned types which name and size are defined with the -sfr- sfr x = 0xf0; // same behaviour
register types types option. sfr variable which overlaps another one will be // as any variable of
considered as volatile. // integral type
syntax: sfr_type_name variable_name = address; address
must be an integer constant.
restrictions: sfr and sbit types are only allowed in
declarations of external global variables.
3 sbit type syntax: sbit sbitname = EXPR ^ bitnumber; sfr x = 0xF0; //
sbit sbitname = ADDRESS ^ bitnumber; sbit x1 = x ^ 1; // 1st bit of x
sbit sbitname = ADDRESS; sbit x2 = 0xF0 ^ 2; // 2nd bit of x
sbit x3 = 0xF3; // 3rd bit of x
semantic: each read/write access of a sbit variable is sbit y0 = t[3] ^ 1; // exprs can also
replaced by an access of the corresponding sfr/variable // be mapped with
access. // sbit
only external global variables can be mapped with a ----
sbit variable. allowed expressions for EXPR are /* file1.c */ | /* file2.c */
integer variables, cells of array of int, struct/union sbit x = P0 ^ 1;| extern bit x;
integral fields, ... . a sbit variable can also be declared | x = 1;//set the 1st
//bit of P0 to 1
as 'extern bit' in an another file.
4 absolute variable syntax: type_name var_name _at_ constant; int x @ 0xFE ;
location type_name var_name @ constant; static const int y @ 0xA0 = 3;
allowed constants are integers, strings and identifiers.
no semantic support: absolute variable locations are ignored
(even if declared with a #pragma location).
5 interrupt functions syntax: void funcname (void) <interrupt id> <= number> void foo1 (void) interrupt XX = YY
<using bankname> <_task_ id> <_priority_ prio> { ... } using 99 { }
warnings: "interrupt handler detected : funcname" void foo2 (void) _task_ 99
"task entry point detected : funcname" _priority_ 2 { }
6 extended keywords keywords removed during preprocessing:
- memory type qualifiers: alien, bdata, code, data, far, idata,
pdata, xdata, ebdata, huge, sdata, xhuge
- memory models: small, compact, large
- function attributes: re-entrant
2-68
IAR Dialect Support
Language Description Example
Extension
1 bit type if initialized with values 0 or 1, a variable of type bit is a bit y1 = s.y.z.2; // exprs can also
simple bit variable (like a c++ bool or a keil bit). be
else, a variable of type bit is a register bit variable (mapped // mapped with sbit
with a bit, a sfr, ..) like a keil sbit. bit x4 = x . 4; // sfr-name . bit-
// position (iar)
bit x5 = 0xF0 . 5; // sfr-address .
// bit-position
(iar)
y1 = 1; // <=> 2nd bit of
// s.y.z is set to
1
2 special function unsigned types which name and size are defined with the -sfr- sfr x = 0xf0; // same behaviour
register types types option. sfr variable which overlaps another one will be // as any variable of
considered as volatile. // integral type
syntax: sfr_type_name variable_name = address; address
must be an integer constant.
restrictions: sfr and sbit types are only allowed in
declarations of external global variables.
3 individual bit access individual bits can be accessed without using sbit/bit int x[3], y;
variables. y . 0; // 1st bit of y
allowed for integer variables, cells of array of int, struct/union x[2].2 = x[0].3 + y.1;
integral fields, ...
4 absolute variable syntax: type_name var_name _at_ constant; int x @ 0xFE ;
location type_name var_name @ constant; static const int y @ 0xA0 = 3;
allowed constants are integers, strings and identifiers.
no semantic support: absolute variable locations are ignored
(even if declared with a #pragma location).
5 anonymous members of unions/structs with no tag and no name can be union { int x; };
structs/unions accessed without naming their parent struct. union { int y; struct {int z;};} @
behavior on conflict between a field of an anonymous struct 0xF0;
with other identifiers : x = y + z;
- with a variable name: field name is hidden
- with a field of another anonymous struct at different scope:
closer scope is chosen
- with a field of another anonymous struct at same scope:
error "anonymous struct field name '%s' conflict"
6 no_init attribute a global variable declared with the no_init attribute is handled no_init int x;
like an external variable. no_init union { int y; } @ 0xFE;
no_init is handled like a type qualifier. #pragma 'no_init' has
no effect.
7 interrupt functions syntax: <interrupt> [<id>] <using [bankname]> void interrupt [XX] using [99]
<funcname> (void) { ... } void foo1 (void) { }
<monitor> [<id>] void <funcname> (void) { ... } monitor [YY] foo2 (void) { }
warnings: "interrupt handler detected : funcname"
8 extended keywords keywords removed during preprocessing:
saddr, reentrant, reentrant_idata, non_banked, plm, bdata,
idata, pdata, code, data, xdata, xhuge
2-69
2.6.9 Warning/error messages format in the log file
Warning/error message given by Polyspace in the log file has the format defined, as follows.
$FILE, line $line (column $col): type: message
 “column” is optional
Example. $FILE, line $line: type: message
 “line” is optional
Example. $FILE: type: message
 “file” (optional) is the fullpath of the involved file.
Example. type: message
 type=[error|remark|warning|catastrophic error|internal error|
link error|command line error|limitation| User Program Error]
Type is not case sensitive
 The message can be on several lines, each new line must start with ‘|’
$FILE, line $line (column $col): type: message_11
| message_12
| message_13
2.6.10 Description of PSCP file

The first line contains the legend of fields used by PSCP file (described below).
The second line contains the application name and the summary of the checks numbers for the
application. This line starts with a “-“.
The PSCP file:

For each package, file, subprogram, or check (called item in the following section , one line
containing its characteristics (color, line, column…) is printed. Further on in this document, this
line will be called CL (characteristics line). These lines begin with a pattern of the form | -
or like | | | … | - for sub-fields.
If the CL describes a package, file or subprogram, it will begin with a pattern of the form | |
-
2-70
If the CL describes a check, it will begin with a marker that indicates the color of the check:
 V indicates that a check is an impossible error

 ? indicates that a check is a possible error
 X indicates that a branch is unreachable
 ! indicates that a check is a certain error
To make the information easier to extract from this file, fields are separated by a tabulation
character (\t). Fields are described in the following section.
At the end of the PSCP file there is a section called LIST OF CODE PROVER OPTIONS
which gives options used for the verification.

Procedural entities
This view contains a tree structure
 The first level of the tree displays :
- In C language: source files (.c files)
- In C++ language: source files (.cpp files)
 Others levels of the tree display :
- In C language: functions or checks found in analyzed source code
- In C++ language: functions and methods or checks found in analyzed source code
R
Indicates the number of red checks (certain errors) in the package, file or subprogram, or if a
check is a certain error
O
Indicates the number of orange checks (possible errors in the package, file or subprogram, or if a
check is a possible error)
Gy
Indicates the number of unreachable branches in the package, file or subprogram
2-71
Gn
Indicates the number of green checks (error does not occur) in the package, file or subprogram,
or if a check is an impossible error
Line
Contains the localization (line number) of the item
Col
Contains the localization (column number) of the item
%
Indicates the selectivity rate of each subprogram, package, or file.
Selectivity rate is given by the ratio: all checks except orange ones / total checks number:
Number of (green checks + red checks) .

Number of (green checks + red checks + orange checks)
Note - Dark orange checks are considered as orange checks.
Details
Gives the explanation of the check given, if one exists.
Macro Code
Internal code that represents the check type and its color
Reviewed
Indicates if the item is reviewed or not. A reviewed item is indicated by an “X” character.
Comment
Displays the comment given for an item using the the Polyspace environment, if one exists.
Scalar/Float
Contains the answer to the question Is the check a scalar?
 Scalar – if the check is a scalar one
 Float – if the check is a float one
 Empty – if no information is provided
2-72
Location file
Contains the localization (file name) of the item
Context
Gives the contextual orange value of the check if provided
2.6.11 Description of the Extended DRS format

2.6.11.1 General information
The Extended DRS file is an XML file containing user data eligible for modification by the -
data-range-specifications option.
To be identified by the Polyspace Code Prover as a valid Extended DRS file, the XML file must
contain the following comment on a new line:

This line may change according to the future evolutions of the file format.
2.6.11.2 Syntax description – XML Marks

The following marks are recognized:
 <global>: This mark is used to declare the global scope. It must be the root element of
the XML file. It may contain any other recognized mark. Global variables may be
defined right under this mark. It has no elements.
 <file>: This mark is used to declare a file scope. This mark must be enclosed in the
<global> mark, and may enclose any variable or function declaration mark. Static
variables must be enclosed in a file mark to avoid conflicts. For the elements description,
see the next section.
 <scalar>: This mark is used to declare an integer or a floating point variable. It may
be enclosed in any recognized mark, but cannot enclose any mark. This mark is used to
set init/permanent/global asserts on variables. For the elements description, see the next
section.
 <pointer>: This mark is used to declare a pointer variable. It may enclose any other
variable declaration mark including itself, to define the pointed objects. It is used to set
what value will be written into pointer (NULL or not), how many objects will be
allocated and how the pointed objects will be initialized. For the elements description,
see the next section.
2-73
 <array>: This mark is used to declare an array variable. It may enclose any other
variable definition mark including itself, to define the elements of the array. Arrays can
also be declared directly with their element type mark. For the elements description, see
the next section.
 <struct>: This mark is used to declare a structure variable or object (instance of
class). It may enclose any other variable definition mark including itself, to define the
fields of the struct. For the elements description, see the next section.
 <function>: This mark is used to declare a function or class method scope. It may
enclose any variable definition mark, to define the arguments and the return value of the
function. Arguments should be named “arg1, arg2, …argn” and the return value should
be called “return”. For the elements description, see the next section.
2.6.11.3 Syntax description – XML Elements

<file> mark:
Attributes
name (**) comment (*)
name main_generator
<scalar> mark:
Attributes
Name line base_type Attributes complete_ init_ init_ init_ global_ assert_ comment
(**) (*) (*) (***) type(*) mode modes_ range assert range (*)
allowed
(*)
name line intx volatile MAIN_ single range YES range comment
uintx extern GENERATOR value disabled NO disabled
floatx static IGNORE (****) unsupported disabled unsupported
const INIT unsupported
PERMANENT
disabled
unsupported
2-74
<pointer> mark:
Attributes
Name line Attributes complete_ init_ init_ initialize_ number_ init_ comment (*)
(**) (*) (***) type(*) modN modes_ pointer allocated pointed
allowed (*****)
(*)
name line volatile MAIN_ single Maybe NULL single value MAIN_ comment
extern GENERATOR value Not NULL disabled GENERATOR
static IGNORE (****) NULL unsupported NONE
const INIT SINGLE
PERMANENT MULTI
disabled disabled
unsupported
<array> and <struct> marks:
Attributes
Name (**) line (*) complete_type (*) attributes (***) comment (*)
name line type volatile comment
extern
static
const
<function> mark:
Attributes
Name (**) line (*) main_generator_called attributes (***) comment (*)
name line MAIN_GENERATOR static comment
YES extern
NO unused
disabled
(*) Attributes used only by the GUI. Those attributes are not mandatory for the ranges to be
accepted by the Polyspace Code Prover. The attribute line contains the line number where the
variable is declared in the source code, complete_type contains a string with the complete
variable type, and base_type is used by the GUI to compute the max and min values. The
attribute comment is used to add information about a node.
(**) The attribute name is mandatory for scope marks <file> and <function> (except for
function pointers). For other marks, name must be specified when declaring a root symbol or a
struct field.
2-75
(***) Values in the field attributes must be separated by white spaces. Only the static attribute is
mandatory, to avoid conflicts between static variables having the same name. An attribute can
be defined multiple times without impact.
(****) The attribute init_modes_allowed is used by the GUI to determine which init modes are
allowed for the current element according to its type. The value works as a mask, where the
following values are added to specify which modes are allowed:
 1 : The mode “NO” is allowed.
 2 : The mode “INIT” is allowed.
 4: The mode “PERMANENT” is allowed.
 8: The mode “MAIN_GENERATOR” is allowed.
For example, the value “10” means that modes “INIT” and “MAIN_GENERATOR” are
allowed. To see how this value is computed, refer to next section.
(*****) Note that a sub-element of a pointer (i.e. a pointed object) will be taken into account
only if init_pointed is equal to SINGLE or MULTI.
2.6.11.4 Valid modes and default values

Gassert Init
Scope Type Init modes mode Initialize pointer allocated Default
Unqualified/ MAIN_GENERATOR
static/ IGNORE YES Main generator
const INIT NO dependant
scalar PERMANENT
Base type
Global PERMANENT
variables Volatile scalar PERMANENT disabled min..max
INIT YES
Extern scalar PERMANENT NO INIT min..max
Struct Struct field Refer to field type
Array Array element Refer to element type
Unqualified/
static/ MAIN_GENERATOR May be NULL NONE
const IGNORE Not NULL SINGLE Main generator
Pointer scalar INIT NULL MULTI dependant
Volatile pointer unsupported unsupported unsupported
2-76
Gassert Init
Scope Type Init modes mode Initialize pointer allocated Default
May be NULL NONE INIT
IGNORE Not NULL SINGLE May be NULL
Extern pointer INIT NULL MULTI max MULTI
Pointed
volatile
scalar unsupported unsupported
Pointed
extern INIT
scalar INIT unsupported min..max
Pointed MAIN_GENERAT
other MAIN_GENERATOR OR
scalars INIT unsupported dependant
May be NULL NONE MAIN_GENERAT
Pointed MAIN_GENERATOR Not NULL SINGLE OR
pointer INIT unsupported NULL MULTI dependant
Pointed
function unsupported unsupported
Scalar MAIN_GENERATOR INIT
parameters INIT unsupported min..max
Userdef May be NULL NONE INIT

function Pointer MAIN_GENERATOR Not NULL SINGLE May be NULL
parameters INIT unsupported NULL MULTI max MULTI
Other
parameters Refer to parameter type
Function Scalar
parameters parameter disabled unsupported
NONE
Pointer SINGLE
Stubbed
parameters disabled disabled MULTI MULTI
function
Pointed PERMANENT
parameters PERMANENT unsupported min..max
Pointed const
parameters disabled unsupported
Userdef
function Return disabled unsupported
disabled disabled PERMANENT
Function
Scalar return PERMANENT unsupported min..max
return Stubbed
Maybe NULL NONE PERMANENT
function
Not NULL SINGLE Maybe NULL
Pointer return PERMANENT unsupported NULL MULTI max MULTI
Note If the base type of a scalar described in this table is enum, the default values for the range
are enum_min...enum_max instead of min..max.
2-77
2.6.12 Description of the Code metrics
2.6.12.1 Definition and implementation
See Section 2.6.8.1 in Polyspace Bug Finder Tool Operational Requirements.
2.6.12.2 File format

See Section 2.6.8.2 in Polyspace Bug Finder Tool Operational Requirements.
2-78
3 Polyspace Code Prover for C++
Operational Requirements
The following sections list the Polyspace Code Prover for C++ capabilities that are supported by
the DO Qualification Kit. To claim certification credit, the user is responsible for determining
the applicability of the Polyspace Code Prover for C++ capabilities supported by the DO
Qualification Kit to their project.
3.1 Input Requirements
3.1.1 Input Requirements for Analysis Mode
OR-340: Polyspace Code Prover shall allow users to specify the application language
to analyze
 The user can specify the language analyzed with the option -lang.
 Polyspace Code Prover must verify that the language is CPP in case insensitive manner.
 If the language is different from CPP, Polyspace Code Prover must stop the execution
target
-OS-target.
 The known operating system targets are Solaris, Linux, VxWorks, Visual, and
no_predefined_OS.
 If none is specified, the default value depends on the OS of the machine that the
verification is running. If the verification is performed on a Linux OS, -OS-target
default value is “Linux”. If the verification is performed on a Windows machine, -OS-
target default value is “Visual”.The given operating system target must correspond
to the given include directories, as it indicates to Polyspace Code Prover what set of
defines is to be used when preprocessing the include directories. If the given include
directories do not correspond to the given operating system, Polyspace Code Prover
displays a warning.
OR-350: Polyspace Code Prover shall allow users to specify the C++ dialect
 The user can specify the language analyzed with the option -dialect.
 Polyspace Code Prover must verify that the dialect belongs to this list: default, iso,
cfront2, cfront3, visual, visual6, visual7.0, visual7.1, visual8, visual9.0 gnu.
 If the dialect does not belong to the list, Polyspace Code Prover must stop the execution
3-2
 If the dialect is visual* (visual, visual6, visual7.0, or visual7.1, visual8 or visual 9.0) and
-OS-target is not chosen as Visual, Polyspace Code Prover must stop the execution
and display an error. Otherwise, options -discard-asm, -OS-target visual are
set by default. Option -dos is also set by default under Linux and Solaris operating
systems.
 The value “visual” is equivalent to “visual7.1”.
 The default value is “gnu” if the value of -OS-target is “linux”, otherwise the default
value is “default”.
 If the chosen value is visual6, visual7.0, visual7.1, visual8 or visual9.0, Polyspace Code
Prover will allow syntaxic permissivity w.r.t than Microsoft Visual C++ compiler, in
particular :
- #pragma pack construct
- Anonymous structure
- Structured exception handling
- #import directives
 The following items are not supported. If one is found, Polyspace Code Prover must stop
with a limitation message or a compilation error.
- Zero length array used in non-pointer context
- C++/CLI extensions
- Microsoft managed extensions
- __based pointers
 The following items do not have semantic support. Polyspace Code Prover ignores them
:__declspec directives with parameter allocate, appdomain, jitintrinsic, naked, noalias,
noinline, noreturn, nothrow, novtable, process, restrict, thread
 If the chosen value is gnu, Polyspace Code Prover will allow syntaxic permissivity with
respectto than gcc 3.4 compiler, in particular:
- #pragma pack construct
- Variable length array
- Anonymous structure
3-3
 The following items are not supported. If one is found, Polyspace Code Prover must stop
with a limitation message or a compilation error.
- Zero length array used in non-pointer context
- keyword __thread
- statement inside expression : if ( { int I = g() ; I ; }) { … }
- c99 features allowed with gcc
- address of label / goto pointer
 The following items do not have semantic support. Polyspace Code Prover ignores them:
- No semantic support for __attribute__
- No special stubs for built-in function (__builtin_exit, …)
OR-350.1 : Polyspace Code Prover shall allow users to slightly modify the C++ dialect
 The user can specify if wchar_t should be considered as a keyword with the option -
wchar-t-is. The two possible values are “keyword” and “typedef”. The value
“typedef” is the default when -dialect is set to visual6, visual7 or visual7.1, the value
“keyword” is the default when -dialect is set to cfront2, cfront3, visual8, visual9.0,
iso, gnu or default.
 The user can change the scope of the for loop index with the option -for-loop-
index-scope. The two possible values are “out” (that means that for loop index is
accessible after the end of the loop) and “in” (not accessible). The value “out” is the
default when -dialect is set to cfront2, cfront3, gnu, visual6, visual7 or visual7.1, the
value “in” is the default when -dialect is set to visual8, iso or default. For visual*
dialects the option is compatible with Visual C++ option “/Zc:forScope”.
OR-342: Polyspace Code Prover shall allow users to specify the main subprogram of
application
 The user can specify the name of the main with the option -main. The list of accepted
mains is: "_tmain", "wmain", "_tWinMain", "wWinMain", "WinMain", "DllMain".
 By default, the name of the main is "main".
 Polyspace Code Prover must verify that the main subprogram exists in the source code.
 If the main subprogram does not exist, and the option -main-generator is not set,
Polyspace Code Prover must stop the execution and display an error message.
3-4
OR-343: Polyspace Code Prover shall allow users to specify the application source
files
 Polyspace Code Prover allows giving a list containing sources files to analyze with the
option -sources. If the extension of a file specified by the user is not a valid extension
(lower case matching *.(c|cc|cpp|cxx)), Polyspace Code Prover must stop the
execution and display an error message.
 If a file specified by the user does not exist, Polyspace Code Prover must stop the
execution and display an error message. If a file cannot be selected, Polyspace Code
Prover must stop the execution and display an error message.
 Polyspace Code Prover displays an error message and stops if a source file name contains
one of the following characters: ^ ? # ; " ' & ( ) < > = , \ : |
§, or non-ASCII characters and ASCII characters with ASCII code not in [32,127].
 By default, if the option -sources is not specified, source files with the extension
*.(c|cc|cpp|cxx) (regardless of the upper/lower case difference) in the directory
sources are selected. If Polyspace Code Prover does not find at least one file respecting
the criterion, Polyspace Code Prover must stop the execution and display an error
message.
OR-351: Polyspace Code Prover shall accept sources files that come from a DOS or
Windows file system
 Polyspace Code Prover can accept source files that come from a DOS or Windows file
system with the option -dos. It must handle upper/lower case sensitivity in include file
names and control characters issues.
 It must also handle change “\” to “/” in #include path names.
 This option is set by default in visual mode.
target
-OS-target.
 The known operating system targets are Solaris, Linux, VxWorks, Visual, and
no_predefined_OS.
 If none is specified, the default value is Visual if the dialect is visual, and Linux
otherwise.
 If the chosen operating system target is Visual, and the -dialect is not visual*,
Polyspace Code Prover must stop the execution and display an error message.
3-5
 If the chosen operating system target is Visual, and no dialect is chosen, the default
dialect is visual and the options -dos (under linux and solaris operating systems) and -
discard-asm are set.
 The given operating system target must correspond to the given include directories, as it
indicates to Polyspace Code Prover what set of defines is to be used when preprocessing
the include directories. Polyspace Code Prover must display a warning if an
incompatibility is detected.
OR-300: Polyspace Code Prover shall provide strict or permissive analysis modes
 Polyspace Code Prover can run in permissive mode.
 The permissive mode gives some results quickly, but with a simple model that may not
find all the possible run-time errors. This mode will analyze source files that use
extensions of the standard. This permissive mode is activated by the option -
permissive.
- permissive mode = -allow-unnamed-fields + -allow-undef-
variables + -ignore-constant-overflows + -discard-asm + -
allow-negative-operand-in-shift + -ignore-missing-headers.
OR-314: Polyspace Code Prover shall ignore missing headers

 Polyspace Code Prover can issue a warning instead of an error when some headers are
missing when -ignore-missing-headers option is set.
 When headers are missing, a warning is displayed even if the option -Wall is not set.
 -ignore-missing-headers is incompatible with -strict mode.
 -ignore-missing-headers is automatically set by -permissive option.
OR-408: Polyspace Code Prover shall detect overflows on bitwise-not assignments

 In default mode, overflows are not checked on bitwise-not assignments like:
x = ~ y;
With x and y expressions of the same integral type (signed/unsigned char/short). These
overflows are due to integral promotion.
 These overflows can be detected using option -detect-overflows-on-

operator-not.
3-6
OR-375: Polyspace Code Prover shall analyze several files separately
 Polyspace Code Prover can perform contextual analysis of files separately. In this mode,
each file will be analyzed separately from the others.
 This mode is activated by the option -unit-by-unit. It is available only in
client/server mode. This option is incompatible with -class-analyzer.
 If a file contains a function call without declaration of the corresponding function, the file
will not be analyzed (Polyspace Code Prover will stop on a link failure).
 If a file contains several classes, it will not be analyzed.
 Some files can be analyzed with every unit (for example, libraries). Those files will be
given to Polyspace Code Prover with the option -unit-by-unit-common-source.
OR-384: Polyspace Code Prover shall pursue verification even if some source files
failed to compile
 Same as corresponding C OR-384
OR-365: Polyspace Code Prover shall accept nested unnamed struct or union fields
within anonymous union
 Polyspace Code Prover can accept unnamed structs field and unnamed unions fields
declared in an anonymous union if it is requested by the user with the option -allow-
unnamed-fields.
 Polyspace Code Prover must stop the execution and display an error message if the user
does not specify that unnamed structs fields and unions fields are allowed and that
constructions are used.
With the option -allow-unnamed-fields the following unnamed structure
containing unnamed unions will compile:
struct {
union { int x;
struct {int y; };
};
} s;
s.x = 5; s.w = 5;
OR-303: Polyspace Code Prover shall continue in case of linking errors due to
undefined global variables
 Polyspace Code Prover interrupts the stubbing phase on undefined global variables in
default mode and displays error messages.
3-7
 Polyspace Code Prover can continue the execution on undefined global variables only if
it is specified by the user with the option -allow-undef-variables. Polyspace
Code Prover assumes the following:
- Undefined global variables are initialized and values during the first reading are
random.
- If an undefined global variable is volatile, Polyspace Code Prover supposes that the
variable is initialized and each reading has a random value .
OR-328: Polyspace Code Prover shall continue if case of linking errors due to extern C
declarations
 Polyspace Code Prover must stop the linking phase on incoherency between entities with
different linkage.
 Polyspace Code Prover can continue the execution with the option -no-extern-C.
OR-325: Polyspace Code Prover shall continue if case of errors due to non ISO STL
 Polyspace Code Prover supplies the user with an efficient implementation of part of the
STL.
 The implementation does not respect the norm for :
- <bitset> : std::bit_set.to_ulong() does not fail
- <ios > : function passed to std::ios_base::register_callback are not called
- <streambuf> : all protected and virtual member functions of template class
basic_streambuf are not implemented
- <fstream> : all protected and virtual member functions of template class basic_filebuf
are not implemented
- containers : implementation does not respect the number of times
constructor/destructor are called
- associative containers : map, multimap, set and multiset do not use their comparison
function
- <string> : member functions of traits argument are not called
- exceptions are not raised, instead there is an assertion failure
 If this implementation of the STL is not compatible with the include files of the
application, some errors (pre-processing, compile, or link errors) will arise.
 Polyspace Code Prover can analyze the application without using its implementation of
the STL with the option -no-stl-stubs.
3-8
OR-324: Polyspace Code Prover shall continue the analysis after finding red checks
 Polyspace Code Prover must warn the user about red checks at each level of the analysis,
but must continue as if no error had been found.
 When a red check is found in a branch, the rest of the branch is unreachable but the
analysis can continue in the other branches of the application.
 This behavior allows the user to quickly find a lot of red checks the first time. Then the
red checks must be fixed to relaunch an analysis. The consequence of red checks can be
some dead code.
 Some constant computation may cause compile-time overflows. These overflows are not
translated as checks but as compilation errors that stop the analyses.
OR-304: Polyspace Code Prover shall continue with a shift operation on a negative
number
 The ISO C++ standard states that a left shift has an undefined behavior when used with a
negative left operand. By default, Polyspace Code Prover puts a red check on that
instruction.
 Polyspace Code Prover can accept such an instruction with the option -allow-
negative-operand-in-shift. The result of the instruction covers the full range
of values of the corresponding type, as it is implementation-dependent.
OR-306: Polyspace Code Prover shall be permissive with overflowing computations on

constants
 Polyspace Code Prover detects overflows on signed integral type constants and displays
an error when the value is out of the range of the specified integral type.
 In accordance with the ISO C++ standard, Polyspace Code Prover does not detect
overflows on constants of unsigned integral types and the resulting value is obtained by
applying the modulus one plus the maximum value, which can be represented in the
result.
 Polyspace Code Prover must ignore overflows on signed integral types constants if it is
specified by the user with the option -ignore-constant-overflows. The result
value of the constant expression is obtained by applying the modulus one plus the
maximum value, which can be represented in the result (with sign extension).
OR-307: Polyspace Code Prover shall be more or less restrictive on overflowing

computations on signed and unsigned integers
3-9
OR-393: Polyspace Code Prover shall allow users to specify enum type representation
 The option -enum-type-definition allows Polyspace Code Prover to use other
base types to represent the enum type, depending on the enumerator values and the
argument of this option.
 The possible argument values for the option -enum-type-definition are:
- defined-by-standard (default value): enum types are represented by Polyspace Code
Prover using the first type that can hold all its enumerator values from the following
list: signed int, unsigned int, signed long, unsigned long, signed long long, unsigned
long long.
- auto-signed-first: Polyspace Code Prover uses the first type that can hold all of the
following enumerator values: signed char, unsigned char, signed short, unsigned short,
signed int, unsigned int, signed long, unsigned long, signed long long, unsigned long
long.
- auto-unsigned-first: Polyspace Code Prover uses the first type that can hold all of the
following enumerator values:
 If enumerator values are all positive: unsigned char, unsigned short, unsigned int,
unsigned long, unsigned long long.
 If one or more enumerator values are negative: signed char, signed short, signed int,
signed long, signed long long.
OR-310: Polyspace Code Prover shall discard assembler code

 Polyspace Code Prover stops the execution when detecting assembler code and displays
an error message.
 Polyspace Code Prover can continue the execution if it is requested by the user with the
option -discard-asm. Polyspace Code Prover ignores the assembler code by assuming
that the assembler code does not have side effects on global variables. Delimiters for
assembler code to ignore can be recognized by Polyspace Code Prover (ISO C++
standard specified asm declaration 7.4 § 1 p 123, __asm, __asm__).
3-10
OR-311: Polyspace Code Prover shall allow users to specify the target processor
 Polyspace Code Prover allows users to specify the target processor with the option -
target. By default, the i386 target is chosen.
 Polyspace Code Prover must verify that the target processor is contained in list (sparc,
m68k, powerpc, i386, c-167, x84_64 and mcpu). If the target processor given by
users with the option -target does not belong to the list, Polyspace Code Prover must
stop the execution and display an error message.
 Polyspace Code Prover must model the target processor as follows:
C++ language sparc c-167 M68k Powerpc (32) i386

Char 8, 8 8, 8 8, 8 8, 8 8, 8
Short 16, 16 16, 16 16, 16 16, 16 16, 16
Int 32, 32 16, 16 32, 32 32, 32 32, 32
long int 32, 32 32, 32 32, 32 32, 32 32, 32
long long 64, 64 32, 32 64, 64 64, 64 64, 32
Float 32, 32 32, 32 32, 32 32, 32 32, 32
Double 64, 64 64, 64 64, 64 64, 64 64, 32
long double 128, 64 64, 64 96, 64 96, 64 96, 32
Pointer 32, 32 16, 16 32, 32 32, 32 32, 32
bytes order big endian little endian big endian big endian little endian
minimum 8 8 8 8 8
addressable size
char is signed12 True True True False true
array alignment 8 8 8 8 8
minimum
struct alignment 8 8 8 8 8
minimum
ptrdiff_type Int Int Long Int int
size_t typedef13 unsignint unsignint unsignint unsignint unsignint
wchar_t underlying unsigned unsigned short unsigned unsigned unsigned short
type14 15 short short short
12
13
Option -size-t-is-unsigned-long can be used to modify default expected typedef to unsigned long.
14
“underlying type” is defined in the C++ standard.
15
Option -wchar-t-is-unsigned-long can be used to modify default expected to unsigned long. Apply
whatever -wchar-t is set or not.
3-11
C++ Language x86_64
Char 8, 8
Short 16, 16
Int 32,32
long int 64, 64 / 32,3216
long long 64, 64
Float 32,32
Double 64, 64
long double 128, 64
Pointer 64, 64
bytes order little endian
minimum addressable 8
size
char is singed17 True
array alignment 8
minimum
struct alignment 8
minimum
ptrdiff_t typedef long / long long18
size_t typedef unsigned long / unsigned long long19
wchar_t underlying unsigned short
type20 21
16
The default long int’s size and alignment is 64-bit with -target x86_64 unless -long-is-
32bits is used. The -long-is-32bits is required with -OS-target visual or -dialect
visual*.
17
The default configured sign of plain char (without signed/unsigned) can be overwritten with the
option -default-sign-of-char. Possible values are “signed” and “unsigned”.
18
ptrdiff_t is 64-bit long or long long (when -long-is-32bits is used) with -target x86_64.
19
size_t is 64-bit unsigned long or unsigned long long (when -long-is-32bits is used) with -
target x86_64. Option -size-t-is-unsigned-long has no effect with -target x86_64.
20
“underlying type” is defined in the C++ standard.
21
Option -wchar-t-is-unsigned-long can be used to modify default expected to unsigned
long. Apply whatever -wchar-t is set or not.
For the types char, short, int, long int, long long, float, double, long
double, and pointer, the size in number of bits and the alignment are given.
3-12
OR-390: Polyspace Code Prover shall allow users to define a new target processor
(generic target)
 Polyspace Code Prover allows users to define its owns target processor 8/16 bit MCPU
(Micro Controller/Processor Unit) with int of 16 bits/32 bits width and
pointer of 16 bits (or 32 bits) depending on short or far addressing mode. This kind of
device may have the capacity of floating point computation usually of single precision
(float of 32 bits) or double precision (option).
 The option -target mcpu reconfigures
Micro Controller/Processor target. The default configuration (without any
options) of -target mcpu is:
Size Alignment
char 8 8
short 16 16
int 16 16
long 32 32
long long 32 32
float 32 32
double 32 32
long double 32 32
Pointer 16 16
char is signed
byte order : little endian
wchart_t underlying type is “unsigned short”
size_t typedef is expected to be unsigned int
ptrdiff_t typedef is expected to be be int
 The option -default-sign-of-char [signed¦unsigned] allows the user to

specify if the plain char is signed or unsigned char.
 The option -short-is-8bits represents signed/unsigned short with 8 bits
and without specific alignment. When the option is set, option -wchar-t-is-
unsigned-long is implied, elsewhere the option -wchar-t-is-unsigned-long
may be used to change the wchar_t underlying type.
 The option -char-is-16bits sets the plain, signed/unsigned char size to 16 bits. It is
incompatible with -short-is-8bits and -align 8.
 The option -int-is-32bits represents signed/unsigned integer as 32 bit
long int. Its alignment, when it is used as struct member or array component, is set also to
32 bits (see also the option -align).
3-13
 The option -pointer-is-32bits represents pointer as 32-bit long int. Its alignment,
when it is used as struct member or array component, is set also to 32 bits (see also the
option -align). When the option is set, ptrdiff _t typedef is expected to be long.
 The target MCPU does not support 64-bit integer except with the option -long-long-
is-64bits. Signed/unsigned long long int is treated as 64-bit integer
with memory alignment of 4 bytes boundary (see also the option -align).
 The option -double-is-64bits represents double as IEEE 754 double precision
float with memory alignment of 4 bytes boundary. This option activates the capacity of
double precision floating computation (the option is available for only some targets).
 -align [32|16¦8] sets the largest alignment of all data objects to 4/2/1 byte(s)
(32/16/8 bits) boundary.
- With -align 32, the objects of size greater than 4 bytes, used as struct member or
array component, are aligned at 4 bytes boundary. This is the default value if -align
is not specified.
- With -align 16, the objects of size greater than 2 bytes, used as struct member of
array component, are aligned at 2 bytes boundary individually.
- With -align 8, the objects of size greater than 1 byte, used as struct member or array
component, are aligned at 1 byte boundary. The storage assigned to the arrays and
structures is strictly determined by the size of the individual data objects without
member and end padding.
- When another value is given to -align, Polyspace Code Prover must stop the
execution and displays an error message.
 The options -short-is-8bits, -int-is-32bits, -pointer-is-32bits, -
long-long-is-64bits, -double-is-64bits, and -align should be used only
with option -target mcpu. If an option is used without this specific option, Polyspace
Code Prover must stop the execution and display an error message.
 If the option -pointer-is-32bits is set and the option -int-is-32bits is not
set, option -size-t-is-unsigned-long is implied. Elsewhere, option -size-t-
is-unsigned-long may be used to change the expected typedef for size_t.
 The target MCPU is not compatible with -dialect visual*. If both options are set,
Polyspace Code Prover must stop and display an error message.
3-14
OR-312: Polyspace Code Prover shall stub automatically subprograms without
definition
 By default, Polyspace Code Prover automatically stubs all subprograms which have no
definition.
 Polyspace Code Prover stops the execution and displays an error message if subprograms
implementing tasks or the main subprogram have no definition.
 Polyspace Code Prover does not stub subprograms if it is requested by the user with the
option -no-automatic-stubbing. In this case, if a function does not have any
definition, Polyspace Code Prover stops the execution and displays an error message.
variables and do not throw exceptions.
 Polyspace Code Prover does not call functions given as an argument of such
subprograms.
 Polyspace Code Prover does not return a callable function pointer.
 Stubbing of constructor (resp. destructor, copy assignment) does not call base class or
member variables constructors (resp. destructors, copy assignments).
 Stubbing of operator new and operator new [] does not fail.
 Stubs of function with Visual C++ attribute “__declspec(nothrow)” does not return.
 Pure virtual functions may be stubbed if they are explicitly called.
 Stubbing of member functions operator[+-*/%^&|]=,operator<<=, operator>>=,
operator<<, operator>>, prefix operator++ and prefix operator— return ‘*this’ if types
are compatible.
 Stubbing of non-member functions operator[+-*/%^&|]=,operator<<=, operator>>=,
operator<<, operator>>, prefix operator++ and prefix operator— return first argument if
types are compatible.
 The option -stub-files allows you to specify files that contain exclusively manual
stubs for functions. Polyspace will consider those files as a pool of stubs, and use the
defined functions only if they are called from the analyzed sources. If a function is
defined both in a stub file and a source file, then Polyspace uses the definition from the
source file in the verification without raising any link error. However, if you also specify
the -functions-to-stub option, then Polyspace uses the definition from the stub
file for functions specified by the option.
 The option -functions-to-stub allows to specify functions that you want
Polyspace to stub. If a function is also present in a file specified by the option -stub-
files, then the Polyspace verification uses the definition provided by that file.
3-15
OR-319: Polyspace Code Prover shall automatically stub all subprograms that have no
definition
 Polyspace Code Prover can stub subprograms, including subprograms that have
parameters of a function pointer type. The prototype of this function type can be
incomplete or can also takes a pointer type as parameter.
 If the called function prototype is missing. Polyspace Code Prover tries to derive the
prototypes from the call contexts when they are consistent.
variables.
OR-326: Polyspace Code Prover shall analyze sources of application without a main
subprogram (main generator)
 Polyspace Code Prover can analyze sources of applications without a main subprogram
with the option -main-generator. Polyspace Code Prover generates a main
subprogram that writes random values into global variables and calls the subprograms of
the program with random arguments.
 Function pointers in arguments may not be initialized to valid pointers.
 The option -main-generator can be used even if the application contains a main
subprogram. The main is ignored.
 The option -main-generator can not be set if the options -class-analyzer or -
main-generator-calls are not used.
 If the option -main-generator is used with options -entry-points, -
critical-sections, -exclusion files, Polyspace Code Prover must stop and
display an error message.
OR-327: Polyspace Code Prover shall analyze all the methods of a class instead of a
main (main generator for class)
 If the parameter of the option -class-analyzer is:
- all, all the classes are verified
- None, no classes are verified
- Custom=<list_of_classes>, the list of classes to verify is explicitly given by
the user
 If the option -class-analyzer is used, the generated main will call a subset of
eligible functions.
3-16
 The eligible functions are all the public or protected function defined in the class
parameter and non-inherited, and the constructors, the copy constructors, and the
destructor, even if private.
If the set of eligible functions is empty, Polyspace Code Prover must stop and display an
error message.
 The generated main calls for each class: first the eligible constructors, then all the eligible
methods, then the eligible destructor.
 The option -class-only is available only with option -class-analyzer. With this
option, all functions defined outside the class are stubbed, except when -class-
analyzer-calls is set, then the inherited functions are analyzed also.
 The option -class-analyzer-calls is available only with option -class-
analyzer. If the parameter of -class-analyzer-calls is:
- all: Default. Generated main calls all public and protected methods of the specified
classes. Members inherited from a parent class are not called.
- all-public: Generated main calls all methods except protected methods.
- inherited-all: Generated main calls all public and protected methods of specified
classes and their parents.
- inherited-all-public: Generated main calls all public methods of specified
classes and their parents.
- unused: Generated main calls all methods that are not called within the specified
classes.
- unused-public: With the exception of protected methods, generated main calls all
methods that are not called within the specified classes.
- inherited-unused: Generated main calls all public and protected methods of
specified classes and their parents that are not called by another method.
- inherited-unused-public: Generated main calls all public methods of
specified classes and their parents that are not called by another method.
- custom=<list_of_methods>: Generated main calls methods that you provide in
<list_of_methods>.
3-17
 In the following example, using -class-analyzer Current, the generated main
will call f( ) and g( ).
class Base {
public:
void bg(){
}
void bf(){
bg();
}
};
class Current : public Base {
public:
void g(){
}
void f(){
g();
}
};
The limitation is:
If the hierarchy to analyze contains more than two classes that are derived from a same
root, the root class is not to be analyzed.
 The generated main verifies that constructors initialize scalar, float, and pointer member
variables of the analyzed class by adding NIV or NIP checks in the generated main. If the
option -no-constructors-init-check is set, verification is not done.
 If the option -class-analyzer is set, the option -main-generator is set
automatically.
OR-327.1: Polyspace Code Prover shall analyze all the functions of a file instead of the
main
 If the option -main-generator-calls is set, the generated main will call a subset
of eligible functions.
 The eligible functions are the functions defined in the source files outside classes. If the
set of eligible functions is empty, Polyspace Code Prover must stop and display an error
message.
 The subset of eligible functions called in the generated main depends on the value of the
parameter. If the parameter of option -main-generator-calls is:
 all, all the eligible functions are called
3-18
 unused, eligible functions not directly called by another eligible function are called. A
function that is called only indirectly (through a variable of a function pointer type) is
considered as unused
 custom=<list>, the list of called functions is explicitly given by the user.
 none, no function will be called
The list of functions contains a list of short name (name without signature ex f for f(int *))
separated by comas.
If the name of a function from the list is not associated with a defined function, Polyspace
Code Prover must stop and display an error message.
If the name of a function from the list is ambiguous, functions with the same short name
are called.
If a function from the list is not eligible, Polyspace Code Prover must stop and display an
error message.
 The generated main calls the selected functions in no specific order.
 If the option -main-generator-calls is set, the option -main-generator is
set automatically.
 The option -main-generator-calls can be set with option -class-analyzer.
If this is the case, and if the sources of the application contain a main subprogram, there
is a warning and the main subprogram is kept.
OR-329: Polyspace Code Prover shall restrict the analysis to functions of a class (class
only)
 Option -class-only can be used only with option -class-analyzer. If option -
class-analyzer is not used, Polyspace Code Prover must stop and display an error
message.
 Option -class-only cannot be used with option -no-automatic-stubbing. If
both options are used, Polyspace Code Prover must stop and display an error message.
 With the options -class-only -class-analyzer A, only functions from class
A are analyzed. Functions out of class A are automatically stubbed even though they are
defined in the source code.
3-19
OR-329.1: Polyspace Code Prover shall control the generated main
 The list of functions specified as parameters of the option -function-called-
before-main will be called by the generated main:
- after constructor calls and before other selected method calls of the belonging class if it
is a method
- after initialization of the global variables and before other selected function calls if it is
a function out of class
 If one of the given name is ambiguous, every corresponding function will be called
 If one of the given names is not associated with a defined function, Polyspace Code
Prover displays a warning message and continues.
 The parameter of the option -function-called-before-main can not be a
default main ("main", or one of the following names if -OS-target has been set to
“Visual”: "_tmain", "wmain", "_tWinMain", "wWinMain", "WinMain", "DllMain").
 The option -main-generator-writes-variables allows the user to define
which variables and how the variables are written in the main.
- uninit (Default): The generated main writes random into each
variable without initialization in the code. The undefined variables are considered as
initialized when -allow-undef-variables is set.
- none: The generated main does not write into a variable.
- public: The generated main writes random into each global and
extern variable. Const and static variable remain unchanged.
- all: The generated main writes random into each global, extern,
const and static variable.
- custom: The generated mail writes random into the list of variables given as
parameters. If the full variable name is given, only the given variable will be
randomized. If a partial variable name (‘a’ for example) is given, the set of variables
associated to the partial name (B::a, C<int>::a and D::f(int, double)::a for example) will
be randomized.
 The options -function-called-before-main and -main-generator-
writes-variables are available only if one of the following options is in use: -
class-analyzer or -main-generator-calls.
 The option -main-generator-files-to-ignore allows you to specify a list of
files or folders for which defined functions are not called by the automatically generated
main. If folders are specified in this list, files in the folder and its subfolders are ignored
by the main generator.
3-20
OR-352: Polyspace Code Prover shall be useable for small applications (desktop)
 By default, Polyspace Code Prover can analyze sources of applications without limits for
a number of assignments and subprograms calls if the license file contains a Polyspace
Server license.
 With the option -desktop, Polyspace Code Prover stops the analysis when there are
more than 3000 assignments and subprogram calls. This option will check the license file
for the presence of a specific line identifying the Polyspace Client instead of the generic
Polyspace Server line.
 If the options -desktop and -class-analyzer are set, Polyspace Code Prover
does not stop if no main is found.
 If the option -desktop is set and -class-analyzer is not set, Polyspace Code
Prover stops if no main is found.
OR-331: Polyspace Code Prover shall allow users to specify the verification precision
level
 Several verification phases exist:
- C++ source compliance Checking (cpp-compliance)
 This phase must check the compliance of source code before the phase source
normalization.
 Some compilation and linking errors can be found and therefore the analysis is
stopped. The errors are displayed in the log file.
- C++ source normalization (cpp-normalize)
 This phase must normalize the C++ source before the phase C++ Linking Phase.
 Some limitations can stop the execution at that level. The limitations are described
in the log file.
- C++ Linking Phase (cpp-link)
 This phase must link the normalized sources before the phase C++ to Intermediate
Language translation.
 Some warning can appear at that level in the log file.
- C++ to Intermediate Language translation (cpp-to-il)
 This phase must generate some intermediate language.
 Some red checks can be found at that level but no graphical result is provided. The
errors and their locations are listed at the end of the log file.
3-21
 The user can launch an analysis to a given verification phase with the option -to. The
user can re-launch analysis from a verification phase already performed with the option -
from.
OR-355: Polyspace Code Prover shall initialize variables with user-defined ranges
 Polyspace Code Prover can initialize file scope, namespace's global/static variables with
user-defined ranges by using the -data-range-specifications option.
 The argument for this option is a file name. This file can be either a user-defined file or
the automatically generated template (see OR-405: Polyspace Code Prover shall generate
default data range specifications (DRS)).
 The user-defined DRS file should contain : var_name val_min val_max
[init|permanent|globalassert], formated as text with "tab" "," (comma), " "
(space) or ";" (semi column) as allowed separators. val_min and val_max could be
replaced by words min or max, corresponding to possible min and max values for var.
The variable name needs to be fully qualified: if the variable ‘v’ is in namespace ‘N’,
N::v should be specified even if ‘v’ is unique. To select a field of a global variable, the
natural syntax “$var.$field” should be used. For the static or const-qualified variables,
the user should use the base name of the file where the variable is defined as prefix
(myfilename.cpp:mynamespace::myclass::mypublicvar for example)
 The automatically generated template, called Extended DRS, is an XML file editable
with the GUI. It contains the same information as the user-defined format in a structured
way. The format complete syntax is described in 2.6.11.
 To define range values, symbolic values min or max can be used, corresponding to the
possible minimum and maximum values of the variables type. For enum type, new
symbolic values enum_min, and enum_max can be used to designate the minimum and
maximum of the enumeration constants defining the enum type. The values out of
enumerations range or min and max can be used for backward compatibility, in that case,
enum type is interpreted as int.
 Polyspace Code Prover can force the range of value for a stubbed function or user-
undefined class method return. The syntax of the user-defined DRS file is:
My_function_bar.return val_min val_max permanent
My_namespace::my_class::get_attr(int).return -2 2 permanent
(where return is a reserved word indicating the return of function). Function name can be
specified in the short form "f" in the case where no ambiguity exists, otherwise it must be
specified in the complete C++ form (ex "f(int, int)"). Typedefs are not supported in this
form. init and globalassert modes can be used on same variable. The
globalassert range must contain the init range.
3-22
 Polyspace Code Prover can range parameters’ values for user-defined functions or class
methods called by -main-generator-calls or -class-analyzer-calls
options. Ranges specified on user-defined functions or class methods that are not called
by the main generator will be ignored.
 Example of an user defined DRS file:
# x Equal to [12;100]. int x=0; is ignored
x 12 100 init
# y volatile variable with subrange [0; 10000]
y 0 10000 permanent
z 0 1 globalassert
w min max permanent #w ranged volatile full-range
v 0 max globalassert #v positive
bar.return -100 100 permanent # function bar returns -100..100
B::f(int,double,char*).#0 1 max init # where #0 is the first argument
 Allowed types of variable for this option are :

int yes yes yes integers: char, short, int, ...
When the range is given in floating point
form, rounding is applied (*).
enum yes yes yes Range can be given in integer or floating
point form (rounding is applied)
float yes yes yes floating types: float, double
volatile no yes no
class/union/struct field yes yes yes integers or floating types only. No
accessibility check is performed.
Impossible to select a field from a base
class.
array yes yes yes array of (array of …) integers or floating
types only. The whole array is constrained.
array cell no no no array[0], ...
bool yes yes yes Allowed values are : min, max, false, true,
0 and 1.
The global assert check show the range
[01]
Pointers no no no
Class / Struct / Union no no no
Stubbed function and no yes no Stubbed function returning integral or
class method return floating points
Stubbed function and no no no
class method parameters
User-defined function or yes no no Functions or method called in the
class method arguments generated main having as argument of
integral or floating types
3-23
Userdef function return no no no
(*) the rounded range covers the original range (example [-12.1, 345.0001] is rounded to [-13,
346]) except the result is out of range of an integer (it will be ignored).
 init mode bypasses the variable initialization to initialize the variable with user-
defined range. Complex initialization performed by constructors or function calls are
problematic, since called functions may read and write global variables. Ranges specified
for “init” mode are valid both before and after user dynamic initializations.
 permanent mode sets the variable in its given range, even if it is written with out-range
values.
 globalassert mode is equivalent to global_assert( var>=min &&
var<=max).
 News checks generated by the globalassert mode are viewable in the Polyspace
environment. “COR” category and have a message of the form
“[certain|possible|impossible] failure of global assertion condition \[$file.$var in the
range of $min...$max\]”.
 Variable specified in DRS file are not considered for -main-generator-write-
variables. Variables that match -main-generator-write-variables mode
will silently not be written by main generator.
 If an error occurs in the configuration file, only a warning is printed and the line is
ignored. Warnings are all prefixed with “Warning: data-range-
specifications:$filename:$line: “. Error messages are listed below (without prefix):
Not understandable line incorrect line. Expected format is "variable-name" min max
[init|permanent|globalassert].
Variable twice in ‘$var_name’ mentioned twice or more. Only ‘init’ and ‘globalassert’ can be used
configuration file at the same time.
Incorrect value specified incorrect range specified for '$var_name': [$min..$max]. Make sure that values
(int) are correct integers, or min/max.
Incorrect value specified incorrect range specified for '$var_name': [$min..$max]. Make sure that values
(float) are correct floating points number (using ‘.’ as delimiter) or min/max.
Incorrect range incorrect range specified for '$var_name': [$min..$max]. Make sure the minimal
value is smaller than the maximal one.
Too big/ too small value in incorrect range specified for '$var_name': [$min..$max]. Make sure the specified
range range fits in the type size ([$type_min..$type_max]).
Incorrect value specified incorrect range specified for '$var_name': [min..max] (allowed value for 'bool'
for a Boolean variable variables are 0,false,min,1,true,max).
Inverse range for Boolean incorrect range specified for '$var_name': [min..max] (values should be
variable inversed).
3-24
Inconsistent range between ‘$var_name’: range for init mode ([min..max]) must be a subset of the
init and globalassert globalassert range ([min2..max2]). This variable has both an ‘init’ and
‘globalassert’ mode, make sure the range for init is smaller than the range for
globalassert.
Volatile variables ‘$var_name’: volatile variables are not allowed in $mode mode. Change the
mode to permanent.
Bad type (pointer, other) ‘$var_name’: type $t is not supported in DRS (limitation). This DRS parameter
will be ignored.
Bad type (class field with ‘$var_name’: class fields are not supported in DRS with permanent mode
permanent) (limitation). This DRS parameter will be ignored.
Bad type (var_name has ‘$var_name’: class types are not supported in DRS (limitation). This DRS
class type and no filed are parameter will be ignored.
specified)
Variable name specify a ‘$var_name’: specified field ‘$f’ does not exist within the type $t: check the type
field but type is definition or remove it from the DRS configuration file.
integer/float
Field does not exist in type ‘$var_name’: specified field ‘$f’ not found. Make sure the field exists and is
spelled correctly.
Variable does not exist / is global variable '$var_name' does not exist, is not used in the current verification
not used or lacks of namespace qualification: make sure the DRS file contains the valid
namespace qualification “Namespace::$var_name”.
Function name is not found stubbed function 'func_name' does not exist or is not used in the current
verification
Function name is function name "g" is ambiguous and may refer to: "g(int, int)", "g(int)", "g()".
ambiguous Give the complete name.
Another mode that 'func_name': return of function is not allowed in $mode mode. Change the mode
permanent is used for to permanent.
function return
OR-356-cpp: Polyspace Code Prover shall check JSF++ rules

OR-378: Polyspace Code Prover shall check MISRA C++ rules

OR-383: Polyspace Code Prover shall check custom rules

3-25
3.1.2 Input Requirements on Code Directives
OR-320: Polyspace Code Prover shall accept included directories
 Polyspace Code Prover accepts a list of UNIX directories to search for included files
with the option -I.
 Polyspace Code Prover must display a warning if an include directory does not exist.
 In C++, if -OS-target is not set,
‘%POLYSPACE_C%/Verifier/include/gnu-linux’ and
‘%POLYSPACE_C%/Verifier/include/gnu-linux/next’ are set at the end of the -I list of
includes folders.
OR-321: Polyspace Code Prover shall allow users to define a list of macro compiler
flags
 Polyspace Code Prover allows users to define a list of macro compiler flags used during
the C++ preprocessing phase with the option -D.
 Polyspace Code Prover allows users to un-define a list of macro compiler flags used
during the C++ preprocessing phase with the option -U.
OR-322: Polyspace Code Prover shall automatically include files in front of all source
files before preprocessing
 Polyspace Code Prover can automatically include some files in front of given source files
before the preprocessing with the option -include.
 Polyspace Code Prover must stop the execution and display an error message if the file
does not exist.
OR-323: Polyspace Code Prover (Visual C++) shall accept an inport directory
 Polyspace Code Prover accepts one directory to be included by #import directives with
the option -import-dir.
 Polyspace Code Prover must display a warning if the import directory does not exist.
 Polyspace Code Prover must stop the execution and display an error message if this
option is used in non-visual mode (-OS-target visual or -dialect
visual*).
3-26
OR-336: Polyspace Code Prover (Visual C++ and Gnu) shall ignore pragma pack
 Visual C++ / Gnu #pragma directives specify packing alignment for structure, union, and
class members. These directives may be ignored to prevent link errors using option -
ignore-pragma-pack.
 Polyspace Code Prover must stop the execution and display of an error message if this
option is used in non-visual mode or non-gnu mode (-OS-target visual or -
dialect visual* or -dialect gnu).
OR-337: Polyspace Code Prover (Visual C++) shall accept pack alignment values
 Visual C++ /Zp option specifies the default packing alignment for the project. Option -
pack-alignment-value transfers the default alignment value to Polyspace Code
Prover.
 The arguments value must be: 1, 2, 4, 8, or 16. If it is not, Polyspace Code Prover must
stop the execution and display an error message.
visual*).
OR-339: Polyspace Code Prover (Visual C++) shall partially manage extensions
 Visual C++ /FX options allow the partial translation of sources making use of managed
extensions to Visual C++ sources without managed extensions. The translated files are
generated in place of the original ones in the project, but the names are changed from
foo.ext to foo.mrg.ext.
 Option -support-FX-option-results allows the analysis of a project containing
translated sources obtained by compilation of a Visual project using the /FX Visual
option.
visual*).
3-27
3.1.3 Input Requirements for Precision of Analysis
OR-330: Polyspace Code Prover shall allow users to specify the analysis precision
level
 Polyspace Code Prover allows users to specify the precision level to be used with the
options -O0, -O1,-O2, -O3. More precision leads to a longer analysis time:
- Level 0 (option -O0) corresponds to interval analysis: loops and relations between
variable values are not analyzed precisely.
more precisely on loops.
more precisely on relations between variables values.
- Level 3 (option -O3) is more precise than -O2, but decreases scaling on huge
applications.
 If the user gives a value which does not belong to the list, Polyspace Code Prover stops
the execution and displays an error message.
 Default value is -O2.
OR-331-a: Polyspace Code Prover shall allow precision tuning by changing the number
of passes
 Two phases are performed whatever the number of passes is chosen.
- Software Safety analysis level 0 (pass0)
 The phase Control and data flow analysis must be done before the phase
Software safety analysis level 1.
 This phase generates the call graph and the data dictionary.
 The results can be displayed in the Polyspace environment.
 Software safety analysis level 1+
- This phase must be done after the phase Software Safety analysis level
0.
- The level of an analysis is the depth of analysis. It starts with Level 1 Software Safety
Analysis and goes up to level 4. Every iterate corresponds to a deeper level of
propagation of calling and called context.
3-28
- Polyspace Code Prover generates information on stubs:
 This information is displayed in the files __polyspace__stdstubs.c,
__polyspace_stdstubscpp.cpp and __polyspace__stlstubs.cpp.
 These files contain the standard stubs function defined by Polyspace
- Polyspace Code Prover generates information on global variables. For each source file
of the application, Polyspace Code Prover generates checks on initializations of global
variables at the declaration. This information is generated in subprograms
_dynamic_init_globals or _init_globals. Calls to these subprograms are
generated at the beginning of the main.
 The user can use option -to and choose a parameter in the following list: pass1, pass2,
pass3, pass4, other where other means twenty passes.
 The user can re-launch analysis from a verification phase he/she has already performed
with option -keep-all-files by using option -from.
 Default value is pass4.
some subprograms
 Polyspace Code Prover allows users with the option -context-sensitivity to
specify a list of subprograms to be more precisely analyzed on each call to it in the
program. Each check inside the subprogram is split into several sub-checks depending on
the call context. Therefore, if a check is red for a call to the subprogram and green for
another call to the subprogram, both colors will be displayed.
 Polyspace Code Prover verifies that each subprogram exists in source code. If not,
Polyspace Code Prover stops the execution and displays an error message.
 The option -context-sensitivity-auto makes Polyspace Code Prover analyze
precisely all the subprograms from the application that call no other subprogram
(terminal in the call-graph).
 The option -context-sensitivity cannot be used with the option -context-
sensitivity-auto.
OR-333: Polyspace Code Prover shall allow users to specify the precision on inter-
procedural analysis
 Polyspace Code Prover allows users to specify the precision on inter-procedural analysis
with the option -path-sensitivity-delta. The precision of propagation of
calling and called context depends of this option.
 By default, the precision on inter-procedural analysis is 0.
3-29
OR-334: Polyspace Code Prover shall allow float rounding according to the IEEE-754
standard to be activated or disabled
 Polyspace Code Prover rounds float according to the IEEE-754 standard.
 If it is requested by users with the option -ignore-float-rounding, Polyspace
Code Prover can perform the exact computation without rounding.
With this option, Polyspace Code Prover can generate results which are not compliant
with the actual floating computations performed in the execution environment.
OR-335: Polyspace Code Prover shall provide absolute address validity checks
 By default, Polyspace Code Prover displays ABS_ADDR checks in orange, because
Polyspace does not have no information about the validity of absolute addresses.
 Option -green-absolute-address-checks specifies that ABS_ADDR checks
should be displayed in green.
3.1.4 Input Requirements for Information

OR-341: Polyspace Code Prover shall allow users to provide the name of application
 Polyspace Code Prover allows users to provide the name of the application to analyze
with the option -prog. This information shows up in the Polyspace environment.
 By default, the name of the application is polyspace.
 Polyspace Code Prover displays an error message and stops if -prog value contains one
of the following characters : $ ^ ? # ; " ' & ( ) < > = , \ : | § , the space character or non-
ASCII characters and ASCII characters with ASCII code not in [32,127].
OR-345: Polyspace Code Prover shall allow users to specify the results directory
 Polyspace Code Prover allows users to specify the directory in which the results of
analysis will be written with the option -results-dir.
 By default, results are written in the directory in which Polyspace Code Prover is
launched.
 If a results directory cannot be created, Polyspace Code Prover must stop the execution
OR-346: Polyspace Code Prover shall allow users to provide the name of the author
 Polyspace Code Prover allows users to provide the name of the author of the analysis
with the option -author. This information shows up in the Polyspace environment.
3-30
OR-347: Polyspace Code Prover shall allow users to provide an analysis date
 Polyspace Code Prover allows users to provide a date for the analysis with the option -
date. This information shows up in the Polyspace environment..
OR-348: Polyspace Code Prover shall allow users to provide a verification version
identifier for the analysis
 Polyspace Code Prover allows users to give a version identifier for the analysis with the
option -verif-version. This information shows up in the Polyspace environment as
the version.
OR-349: Polyspace Code Prover shall display compilation warnings

 Polyspace Code Prover can display warnings during compilation phase in case of
improper declarations or statements while they do not cause fatal errors with the option -
Wall.
 The default mode does not display warnings.
3.1.5 Input Requirement for Scaling Options

OR-360: Polyspace Code Prover shall provide the number of consecutive fields of
structures that pointer analysis distinguishes
 By default, pointer analysis distinguishes fields in complex types.
 Polyspace Code Prover can limit the distinguished depth of types in pointer analysis with
the option -k-limiting. The goal is to help scaling by decreasing precision.
OR-361: Polyspace Code Prover shall allow non-pointer global variables to be declared
as not containing pointers
 By default, Polyspace Code Prover considers that a global or static variable can carry
aliases, even if the variable has a non- pointer type.
 Polyspace Code Prover can trust the declared type of the global variables and stop
carrying pointers through those variables with the option -respect-types-in-
globals. The goal is to increase precision and scaling, only if the source code respects
this requirement, in accordance with the ISO C++ standard.
3-31
OR-362: Polyspace Code Prover shall allow non-pointer fields of structures to be
declared as not containing pointers
 By default, Polyspace Code Prover considers that a structure can carry aliases in its
fields, even if the fields have a non- pointer type.
 Polyspace Code Prover can trust the declared type of the structures and stop carrying
pointers through their fields with the option -respect-types-in-fields. The
goal is to increase precision and scaling, only if the source code respects the requirement.
OR-363: Polyspace Code Prover shall inline some subprograms

 Polyspace Code Prover can inline some subprograms to distinguish each call with the
option -inline. The goal is to increase precision and scaling. The scaling may be
much better if the given subprograms contain a lot of aliases. The scaling may be worse
if the given subprograms are called too many times and are too large.
 If the name specified by the option -inline is a full method or function name, it is
cloned.
 If the name specified by the option -inline is a class name, all the methods of the
class are cloned.
 If the name specified by the option -inline is a method or function short name, all the
methods or functions with the same name are cloned, whatever signature they have.
 If the name specified by the option -inline is not recognized as a C++ name,
Polyspace Code Prover must stop and display an error message.
on all reads and all operators
 With the option -less-range-information, Polyspace Code Prover can improve
computing and providing range and pointer information on read of expressions and on
operators. It gives range information only on assignments of scalars and floats.
on pointers
 With the option -no-pointer-information, Polyspace Code Prover can improve
computing and providing pointer information on read of expressions and on dereference
operators.
 The option -no-pointer-information has no effect if -less-range-
information is already used.
3-32
3.1.6 Input Requirements for Tasking
OR-370: Polyspace Code Prover shall allow users to specify a list of tasks
 Polyspace Code Prover allows users to specify a list of tasks/entry points with the option
-entry-points.
 Polyspace Code Prover must verify that subprograms which implement tasks or entry
points exist and do not have parameters. In other cases, Polyspace Code Prover must stop
the execution and display an error message.
 Tasks or entry points are called by Polyspace Code Prover at the end of the main
subprogram (which is executed sequentially) at the same time (the main subprogram
must terminate).
OR-371: Polyspace Code Prover shall allow users to specify some critical sections
through subprograms
 Polyspace Code Prover allows users to specify some critical sections to model the
behavior of binary semaphores or to model protection of shared resources or interruption
masking with options -critical-section-begin and -critical-section-
end.
 Polyspace Code Prover must verify that subprograms which implement critical sections
exist in source code. If not, Polyspace Code Prover must stop the execution and display
an error message.
OR-372: Polyspace Code Prover shall allow users to specify a set of tasks which are
never executed at same time
 Polyspace Code Prover allows users to indicate a set of tasks which are not executed at
the same time with the option -temporal-exclusions-file.
 Polyspace Code Prover must verify that each task exists. If a task does not belong to the
list of entry points, Polyspace Code Prover must stop the execution and display an error
message.
3.1.7 Miscellaneous
OR-380: Polyspace Code Prover shall launch a command after preprocessing sources
 Polyspace Code Prover can launch a given script or command after the preprocessing,
but before the compilation of the source files with the option -post-
preprocessing-command.
 The command or the script must be valid.
3-33
 It must transform files into a file acceptable for compilation. Otherwise, Polyspace Code
Prover will stop and display an error message.
 It must not change the line numbering. Otherwise, source correspondence is not ensured
during the visualization of the results in the Polyspace environment.
OR-381: Polyspace Code Prover shall allow users to keep temporary files
 At the end of the run, Polyspace Code Prover suppresses temporary files.
 Polyspace Code Prover can keep these files with the options -keep-all-files. The
option -keep-all-files allows user to re-launch an analysis from an intermediate
pass.
OR-358: Polyspace Code Prover shall run analyisis on supported OS

 Polyspace Code Prover can run analysis on the following operating systems:
- Windows
- Linux
 OS updates and service packs are supported by Polyspace Code Prover.
 Functional results obtained on supported operating systems must be identical.
 If the OS on which Polyspace Code Prover is running is not supported, the analysis
continues.
OR-359: Use of Polyspace Code Prover shall be protected by a license mechanism

 Polyspace Code Prover uses two license mechanisms:
- Concurrent license - uses FlexNet® API
- Designated computer license
OR-366: Polyspace Code Prover shall provide remote analysis

 Polyspace Code Prover allows the launching of several analyses launched simultaneously
by several users on their local machines, to be dispatched on several remote machines.
Each remote analysis is split into two separate parts (compilation and analysis) launched
on two different machines (see OPREQS-RL). Some functionalities of remote analysis
can be used in batch mode with Polyspace Code Prover C++ :
- The option -prepare-remote allows running the first part of the remote analysis:
the sources and options verification is performed on the user machine.
 The local analysis stops after pass cpp-compliance.
 This local analysis must run only with a client license.
3-34
 A launching command file named relaunchingCommand.sh is generated in the
results directory to launch the second part of the remote analysis. This launching
command shall be identical to the one used to launch the first part except that the -
prepare-remote option is replaced with -finalize-remote.
 The results of the compilation phase and the newly generated launching command
are compressed and stored in a file named polyspace.tar.gz, located in the results
directory.
- The option -finalize-remote allows running the second part of remote analysis.
If the first part of remote analysis is completed and without error, the RTE analysis is
performed on the remote machine.
 The remote analysis runs from cpp-normalize.
 The analysis can run only with the server license, whatever desktop mode has been
required.
 The results of a remote analysis must be the same as if not remotely launched and
results must be compatible with the Polyspace environment.
OR-367: Polyspace Code Prover shall allow users to execute the post analysis
command
 Polyspace Code Prover can execute a command specified by the user once the analysis is
terminated. This command is given as argument of the option -post-analysis-
command. It is a command/script executable within shell “sh” in the results directory.
 The execution of the given command/script is performed on the machine ending the
remote analysis(client side with -to cpp-compliance, server side otherwise).
 The given command/script is executed when the analysis ends normally (not killed). The
status of the execution (if performed) is warned by Polyspace Code Prover.
OR-369: Polyspace Code Prover shall operate on a multi-core OS

 The option -max-processes <number of processes> allows the user to set
the maximum number of processes that may run simultaneously to perform the
verification on a multi-core machine.
 The value of <number of processes> is limited by the number of cores. It cannot
be greater than 128; an error message is displayed otherwise.
 This option is set by default with the value of argument equal to 4 (e.g. -max-
processes 4).
 To disable the parallelization even on a multi-core machine, it is possible to use the
option -max-processes 1.
3-35
OR-373: Polyspace Code Prover shall use 32-bit or 64-bit addressing mode
 Polyspace Code Prover provides -machine-architecture <argument> option
to set 32-bit or 64-bit addressing modes on 64-bit machines.
 The possible values of -machine-architecture argument are: 32,64,auto.
 The default configuration is -machine-architecture auto. It activates 32-bit
mode.
OR-385: Polyspace Code Prover shall stop verification after a user defined time amount
OR-376: Polyspace Code Prover shall export a verification report

 Polyspace Code Prover may generate a report that summarizes information of the
verification. The report is generated at the end of the full verification, before any post
analysis command (if option -post-analysis-command is used).
 Such a report will be generated if option -report-template is used. The option
takes as argument the name of a template file. That template defines what kind of
information will be inserted in the report and what the overall format will be.
 The format of the report can be HTML, PDF, RTF, Word, (not available on UNIZ
platform) and XML. The option -report-output-format will define the format of
the report. If no format is specified, RTF is used.
 The name of the generated report file can be defined. The option -report-output-
name will define the name of the report file. If no name is specified, the report will be
named: “{Prog}_{TemplateName}.{Format}” ({Prog} being defined by -prog,
{TemplateName} being defined by -report-template and {Format} being defined
by -report-output-format).
OR-377: Polyspace Code Prover shall allow users to annotate coding rule(s) and
check(s) in its source code
OR-394: Polyspace Code Prover shall allow users to import coding rule(s) and runtime
error(s) comments from results folder
 The user can import coding rule(s) and runtime check (s) comment from specified results
folder.
 The option -import-comments allows user to specify the location of a Polyspace

Code Prover results folder.
3-36
OR-395 Polyspace Code Prover shall continue verification if only one source file
compiles
 The option –continue-with-compile-error allows user to continue verification
even if only one file compiles. Files that have compilation errors are not verified. The
verificaiton results may not contain all coding rule violations or errors.
3-37
3.2 Output Requirements
3.2.1 Output Requirements for Call Graphs
OR-400: Polyspace Code Prover shall generate call graphs
 Polyspace Code Prover has to generate a call graph if analysis goes up to Software
 The call graph has to provide for each function foo:
- The subprograms called by foo with localization of the call (file + line + column) and
the subprogram called (file + line + column).
- The subprograms which calls foo with localization of the call (file + line + column)
and the caller (file + line + column).
- The tasks which call foo with localization.
 Calls of the assert function are not given in call graph.
 The call graph has to be generated in an external format usable without the Polyspace
environment, and easily exploitable by users.
3.2.2 Output Requirements for Data Dictionaries

OR-401: Polyspace Code Prover shall generate data tables
 Polyspace Code Prover has to generate a data table if analysis goes up to control and
Software Safety analysis level 0.
 Data table has to provide for each global variable bar:
- Access (read, write) actions for bar with their localization (file + line + column). Read
and write access actions are distinguished by the character < and > (< for write access
and > for read access). For structured variables like union and structure, accesses are
provided at field level. Potential accesses might not be distinguished depending on
alias analysis precision.
- Potential access (read, write) for each dereference of bar with their localization (file +
line + column).
- Access occurring in part of the application that is not executed (unreachable branches,
not called functions) is marked as unreachable
- A range of all the values taken by the variable is provided for scalar variables (i.e.
neither structured variables as union or structure not array variables).
3-38
- Variables that are not read and not written or for which accesses are unreachable are
marked as unreachable
- A summary of bar characteristics as type, range type, range value and declaration
localization.
- Protection used for bar (critical section, temporal exclusion and access pattern)
- If bar is a shared variable.
- A summary of concurrent accessby tasks (read, write).
 Variables declared but not used do not appear in the data table.
 Data table has to be generated in an external format usable without the Polyspace
environment, and easily exploitable by users.
3.2.3 Miscellaneous
OR-402: Polyspace Code Prover shall export run-time checks
 Polyspace Code Prover has to generate run-time checks in an external format usable
without the Polyspace environment, and easily exploitable by users (see Description of
PSCP file) if analysis goes up to Software Safety analysis level 0.
OR-403: Selectivity rate of Polyspace Code Prover results shall not decrease more than
5% between two releases
 Polyspace Code Prover has to provide results with an acceptable selectivity rate.
Acceptable is strongly linked with the application characteristics and the analysis inputs.
 Polyspace Code Prover has to provide a selectivity rate in both alpha and beta mode for
each Software Safety analysis step.
3-39
OR-404: Polyspace Code Prover shall export range values
 Polyspace Code Prover has to generate information on computed ranges for simple types
(integral, character, enumerated, fixed point, or float type) and for pointer types. The
computed range is a superset of all possible values taken during the execution. The
information is provided for non-dead reads of expressions, writes of expressions, and
operators.
 The range and pointer information is provided as tooltips in the Polyspace environment.
This information is not available in the textual output.
 In case of use of the option -less-range-information, only the ranges of the
assignments are computed and exported.
 In case of use of the option -no-pointer-information, information on pointers is
not computed or exported.
OR-405: Polyspace Code Prover shall generate default data range specifications (DRS)
 Polyspace Code Prover automatically generates a template file named “drs-template.xml”
in the result folder for variables, functions, and methods eligible for -data-range-
specifications option. This template can be edited and modified through the data
range specification GUI. It can be re-used as argument of -data-range-
specifications option.
 If a user-defined file has been used with -data-range-specifications option,
information from this file is taken into account in the generated template file.
OR-407: Polyspace Code Prover shall generate source code metrics

See Section 3.2 in Polyspace Bug Finder Tool Operational Requirements.
3-40
3.3 Performance Requirements
3.3.1 Polyspace Code Prover Time Increase Threshold
OR-802: Elapsed time to execute Polyspace Code Prover shall be less than an absolute
time for three applications of BTV
 Polyspace Code Prover has to generate results in time less than an absolute time for three
real applications of the BTV. The time is given for an execution of Polyspace Code
Prover on a RedHat 7.2 machine with the following configuration:
- CPU Intel PentiumIV >= 1.5GHz
- RAM >= 1GB
- SWAP >= 2.8GB
C++ Absolute Precision Level Verification Phase Number of Lines

Time
TOLBIAC_O2 10h O2 Safety Analysis 4 6921
CHEVALERET_O2 5h O2 Safety Analysis 4 257332
DENFERT_QUICK 5h O0 Safety Analysis 0 123156
3-41
3.4 Language-Specific Requirements
For each language-specific version of Polyspace Code Prover, for each language construct, there
is a required semantic support level. There are four such levels: SSL1 ... SSL4. The lowest level,
SSL4, means that the program construct is accepted by Polyspace Code Prover but without any
guarantee of the soundness of its analysis, while the highest level, SSL1, requires Polyspace
Code Prover to fully handle the construct. Full support means that it is accepted syntactically,
processed semantically in a sound manner with respect to the applicable semantic model, and
also, from the point of view of the errors, it may directly generate. The following table
summarizes the four semantic support levels.
Table 3 Semantic Support Levels

Level Construct Effect of construct fully Checks associated to construct
syntactically modeled according to the generated according to the
accepted semantic model, including semantic model
return value
SSL1 Yes Yes Yes
SSL2 Yes Yes No
SSL3 No22 No No
SSL4 Yes No No
22
SSL3 support requires the detection and rejection of the corresponding construct.
A common requirement will be that floating overflows and domain errors are halting the
execution of the subject program. In IEEE-748 terms, it is assumed that the generation of a NaN
or of the infinity halts the computation. This implies that a multiplication that overflows shall be
detected by Polyspace Code Prover as an error (with a corresponding orange or red check). This
corresponds in the IEEE-748 model to have set the exception generation on overflow. This
differs from the ISO semantic model for C++ (for instance) which is compatible with the
generation of IEEE-748 special values, such as infinity and NaN, instead of the generation of
exceptions. Polyspace Code Prover can therefore be stricter than the language standard as
regards floating point exceptional conditions. This is, however, acceptable as Polyspace Code
Prover will thereby signal floating errors according to the strictest semantics.
To summarize, Polyspace Code Prover assumes that floating point overflows are undesirable
run-time errors.
3-42
3.4.1 Semantic Requirements
LSR-400: Semantic reference model for C++ Polyspace Code Prover
The applicable language standard for C++ Polyspace Code Prover is the International standard
ISO/EIC 14882: 1998 (E). C++ is based on the C programming language, as described in
ISO/EIC 9899:1990 Programming Languages – C (1.2).
The language is complemented with the floating point IEEE-748 model and the following:
 Float overflows and domain errors are errors halting the execution of the C++ program.
For IEEE-748, the generation of a NaN or an infinity halts the computation.
 Subprogram parameters are evaluated from left to right.
 Pointer is not stored in objects of floating or enumerated type, then read from these
objects and subsequently de-referenced.
LSR-401: Semantic Support Levels for C++ Polyspace Code Prover

C++ ANSI/ISO constructs, as specified in LSR-400, shall be supported at level SSL2 or SSL1,
with the exception of the following constructs known as limitations:
 Gnats 5405: Covariant virtual function with ellipsis are not supported (SSL3)
 Gnats 10754: block depth should not exceed 1000 (SSL3)
 Gnats 5404: Switch not implemented as a case list are not supported (SSL3)
 Gnats 14099: Dialect GNU: statement expression are not supported (SSL3)
 Gnats 14386: GNU: constant hexadecimal float values are not allowed (SSL3)
 Gnats 6152: Tasks cannot be called in main (SSL3)
 Gnats 4973: VISUAL: Variable length (flexible) structures are not supported (SSL3)
 Gnats 6575: VISUAL C++ SEH : return and goto not allowed in __try body of a __try
__finally construct (SSL3)
 Gnats 14384: GNU: Zero length array are not allowed as variable (SSL3)
 Gnats 6067: VISUAL : __based keyword is not taken into account (SSL3)
 Gnats 5466: Backwards and cross-boundary goto statements are not supported (SSL3)
 Gnats 5467: Threads/tasks with parameters are not supported (SSL3)
 Gnats 4080: Address of critical section must not be taken (SSL3)
3-43
 Gnats 5406: Rethrow outside a catch are not supported (SSL3)
 Gnats 5407: Taking address of C library function with ellipsis is not allowed (SSL3)
 Gnats 5469: Global static arrays, strings, unions or structs greater than 128 Mb are not
supported (SSL3)
 Gnats 5468: Dynamic task/thread creation are not supported (SSL4)
 Gnats 5470: The library functions setjmp(), longjmp(), signal(), raise(), free() are not
supported (SSL4)
 Gnats 9355: pointer initialized to 0 and moved w.r.t. initial value remains null (SSL4)
 Gnats 9757: Alias/rtti/pmf call on "this" during construction/destruction leads to RED
PVC/CTR/DCT/ASSERT/PMF (SSL4)
 Gnats 5110: allocation functions without "throw()" should not return 0 (SSL4)
 Gnats 12896: User allocation functions : new, new[], delete and delete[] are replaced by
internal stubs (SSL4)
 Gnats 11584: Destructor are not implicitly called for global variables (SSL4)
 Gnats 5409: Main, tasks, and C library functions must not raise exceptions (dynamically
detected)
 Gnats 10670: Implementation of defaults new operator does not throw (SSL4)
 Gnats 6578: VISUAL C++ SEH : side effect of __except statement not modelized before
__finally (SSL4)
 Gnats 7900: Red FPPF check in functions with ellipsis signals that the function must not
be called directly (SSL4)
 Gnats 6240: int and long seen as equal in call through pointer (SSL4)
 Gnats 6577: VISUAL C++ SEH : __try __except and __try __finally statements does not
catch hardware exception (SSL4)
 Gnats 8497: VISUAL : __declspec are not supported (SSL4)
 Gnats 6579: VISUAL C++ SEH : resuming an exception in __try __except construct is
not allowed (SSL4)
 Gnats 5408: Exception raised in destructor or delete are not supported (dynamically
detected)
 Gnats 8124: pointer and reference are seen as equal in call through pointer (SSL4)
A check that is associated to all limitations is said to be “dynamically detected”. This check is
computed red by Polyspace Code Prover if the source code violates the limitation.
3-44
3.4.2 Applicable Checks for C++ Polyspace Code Prover
LSR-403: Applicable checks for C++ Polyspace Code Prover
Polyspace Code Prover shall generate checks according to messages from Table 4, with
Semantic Support Levels described in Table 5 for Polyspace Code Prover, Table 6 for the C++
libraries, and Table 7 for the C libraries.
The third column labeled Table 4 indicates:
RE: for run-time errors (stops the execution if red),

Limitation: for dynamically checked limitations (stops the execution if red), or for
coherency checks (does not stop the execution if red)
Information: for information on dynamic calls (does not stop the execution if red).
Most language constructs have level SSL1, while language libraries have level SSL3.
 Polyspace Code Prover is allowed to avoid generating a check if the corresponding

operation involves only constants and the check can be trivially determined as passing
(green) by constant folding.
 Polyspace Code Prover shall generate checks for assertions given by assert (predicate)
whose dynamic semantics is to halt the computation if the predicate evaluates to false.
In some degenerated cases, for example, if the computation of an expression implies some
checks, and its value is not used, no checks will be generated.
For example, the analysis of the following piece of code generates no checks:
struct A {
int j;
};
int main () {
struct A sa;
struct A* a = &sa;
sa.j = -1;
a->j
<<
a->j;
}
3-45
Checks “non null receiver” and “correct structure for receiver” are green inside a member
function on a call to a member function on super-class of the receiver ("this") or on a sub-field
of “this”.
 “Null references” are not forbidden by Polyspace Code Prover: the “pointer within
bound” checks will be red when de-referencing data, but Polyspace Code Prover does not
enforce it when converting pointer to references.
 Reds checks in compiler generated code (a copy constructor that cannot access to source
data, for example) are not displayed in the Polyspace environment.
 It is not specified if red checks depending on compiler-dependant properties are
generated.
class A
{
public :
virtual void f() ;
A(int m) : data(m) { ; }
private : int data;
};
int main()
{
A* p = (A*) malloc(sizeof(int));
new(&p)A(0);
}
Some check messages do not change in function because of their color.
Table 4 Check Messages of C++ Polyspace Code Prover

Category Color Message
NIV ALL Non-Initialized Variable
NIP ALL Non-Initialized Pointer / Non-Initialized Reference
ASSERT ALL Failure User Assertion
OVFL ALL scalar Overflow/Underflow
FL_OVFL ALL float Overflow/Underflow
ZDIV ALL scalar Division by zero
FL_ZDIV ALL float Division by zero
SHF ALL shift amount in [n...p]
SHF ALL left operand of left shift is negative
POW ALL power must be positive
RETURN_TYPE ALL return type of function X is a T1 but a T2 was expected
OBAI ALL array index within bounds
COR ALL array conversion must not extend range
COR (FPPF, ALL function pointer must point to a valid function
FUNC_POINTER_CAST)
3-46
COR ALL wrong number of arguments for call to function F got n instead of m
(WRONG_NUM_ARG)
COR ALL wrong type for argument #n of call to function F type expected a T1,
(WRONG_TYPE_ARG) but got a T2
IDP ALL pointer within bounds / reference is valid
COR ALL illegal pointer access to variable
COR ALL illegal pointer access to structure field
FRV Green function returns a value
Red function does not return a value

Orange function may not return a value
NNR (NNP) Green call to virtual function [f] is not pure
Red this-pointer [of f] is null

Orange this-pointer [of f] may be null
OOP (PVC) Green call to virtual function [f] is not pure
Red call to pure virtual function [f]

Orange call to virtual function [f] may be pure
OOP (DTY) Green this-pointer type [of f] is correct
Red incorrect this-pointer type [of f]

Orange this-pointer type [of f] may be incorrect
OOP (PMF_TYPE) Green pointer to member function points to a valid member function
Red pointer to member function is null or points to an invalid member

function
Orange pointer to member function may be null or point to an invalid member
function
CPP (PAS) Green array size is strictly positive
Red array size is not strictly positive

Orange array size may not be strictly positive
CPP (TID) Green typeid argument is correct
Red incorrect typeid argument

Orange typeid argument may be incorrect
CPP (DCT) Green dynamic_cast on pointer is correct
Red incorrect dynamic_cast on pointer (analysis continues using a null

pointer)
Orange dynamic_cast on pointer may be incorrect
CPP Green dynamic_cast on reference is correct
Red incorrect dynamic_cast on reference
3-47
Orange dynamic_cast on reference may be incorrect
EXC (THR) Green call [to f ]does not throw during "catch" parameter construction
Red call [to f ]throws during "catch" parameter construction

Orange call [to f ]may throw during "catch" parameter construction
EXC Green call [to f ]does not throw during initialization of global variable [v]
Red call [to f ]throws during initialization of global variable [v]

Orange call [to f ]may throw during initialization of global variable [v]
EXC (EXD) Green destructor or delete does not throw
Red throw during destructor or delete

Orange possible throw during destructor or delete
EXC (EXU) Green no exception is thrown
Red exception raised is not specified in the throw list

Orange exception raised may not be specified in the throw list
EXC Green no exception is thrown
Red an exception is thrown but is forbidden by the empty throw

specification
Orange an exception may be thrown but is forbidden by the empty throw
specification
EXC Green main, task or C library function does not throw
Red main, task or C library function throws

Orange main, task or C library function may throw
EXC (CRE) Green call [to f] does not throw
Red call [to f] throws (analysis jumps to enclosing handler)

Orange call [to f] may throw
EXC Green function does not throw
Red function throws (analysis jumps to enclosing handler)

Orange function may throw
EXC Green expression value is not EXCEPTION_CONTINUE_EXECUTION
Red expression value is EXCEPTION_CONTINUE_EXECUTION

(limitation)
Orange expression value may be
EXCEPTION_CONTINUE_EXECUTION(limitation)
EXC Green N/A
Red throw is not allowed with option -no-exception

Orange N/A
3-48
ABS_ADDR Green this absolute address is valid, will allow to dereference this type: < a
type > and the corresponding memory zone is initialized
Red this absolute address is not valid, does not allow to dereference this
type: < a type > and the corresponding memory zone is not initialized
Orange this absolute address may not be valid, may not allow to dereference
this type: < a type > or the corresponding memory zone may not be
initialized
Table 5 Applicable Checks for C++ Polyspace Code Prover

Requ. ISO/IEC Description in ISO/IEC Details Run-time SSL
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1-1 1.9 §4 [Intro.execution] NA
(p. 5) For example, the effect of de-referencing
a null pointer.
LSR-403-1-2 2.13.4 §2 [lex.string] String objects are const. SSL4
(p.19) The effect of attempting to modify a
string literal is undefined.
LSR-403-1-2a 3.6.2 §4 [basic.start.init] No throw during dynamic SSL1
(p.45) If construction or destruction of a non- initialization
local static object ends in throwing an
uncaught exception, the result is to call
terminate (18.6.3.3).
LSR-403-1-2b 3.7 §1 [basic.stc] See also LSR-403-1.2c, LSR- SSL4
(p.45) Storage duration is the property of an 403-1.4a, LSR-403-1.4b
object that defines the minimum
potential lifetime of the storage
containing the object.
LSR-403-1.2c 3.7.1 §1 [basic.stc.static] SSL4
(p.46) Local objects [...] have automatic storage
duration. The storage for these objects
lasts until the block in which they are
created exits.
LSR-403-1-3 3.7.3.1 §2 [basic.stc.dynamic.allocation] C++ differs from C in SSL1
(p. 47) If the size of the space requested is zero, requiring a zero request to
the value returned shall not be a null return a non-null pointer.
pointer value (4.10). If the size is zero, the pointer
The results of de-referencing a pointer points to an object of size one
returned as a request for zero size are byte.
undefined.
LSR-403-1-4 3.7.3.2 §4 [basic.stc.dynamic.deallocation] Trying to de-allocate the On some SSL4
(p. 48) The effect of using an invalid pointer storage referenced by an implementations, it
value (including passing it to a de- invalid pointer causes a system
allocation function) is undefined. Is to be checked. generated run-time
fault.
3-49
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1.4a 3.8 §1 [basic.life] See also LSR-403-1.2b, LSR- SSL4
(p. 48) The lifetime of an object is a run-time 403-1.2c, LSR-403-1.4a
property of the object.
The lifetime of an object [...] ends when
the storage which the object occupies is
reused or released.
LSR-403-1.4b 3.8 §3 [basic.life] See also LSR-403-1.2b, LSR- SSL4
(p. 48) The properties ascribed to objects 403-1.2c, LSR-403-1.4a
throughout this international standard
apply for a given object during its
lifetime.
LSR-403-1-5 3.9.1 42) [basic.fundamental] NA
(p. 53) Using a bool value in ways described by
this international standard as
“undefined”, such as examining the
value of an un-initialized automatic
variable, might cause it to behave as if it
is neither true nor false.
LSR-403-1-6 3.10 §15 [basic.lval] SSL4
(p.56) If a program attempts to access the
stored value of an object through a value
of other than one of the following types,
the behavior is undefined.
LSR-403-1-7 4.1 §1 [conv.lval] SSL4
(p.57) If the object to which the lvalue refers is
not an object of type T and is not an
object of a type derived from T, …, a
program that necessitates this conversion
has undefined behavior.
LSR-403-1-8 4.1 §1 [conv.lval] Non-Initialized variable SSL1
(p.57) If the object to which the lvalue refers … LSR-303-8
is un-initialized, a program that
necessitates this conversion has
undefined behavior.
LSR-403-1-9 4.7 §2 [conv.integral] Conversions from integer type SSL1
(p.60) If the destination type is unsigned, the to unsigned integer type have
resulting value is the least unsigned modulo semantics.
integer congruent to the source integer. LSR-303-1
LSR-403-1-10 NA Conversions from unsigned SSL1
integer type to integer type are
subject to over/underflow
checking.
LSR-303-1
3-50
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1-11 4.8 §1 (p.60) [conv.double] Overflow/Underflow SSL1
An rvalue of floating point type can be Conversion from floating point
converted to an rvalue of another type to floating point type are
floating point type. If the source value subject to under/overflow
can be exactly represented in the checking.
destination type, the result of the LSR-303-3
conversion is that exact representation. If
the source value is between two adjacent
destination values, the result of the
conversion is an implementation-defined
choice of either those values. Otherwise,
LSR-403-1-12 4.9 §1 (p.60) [conv.fpint] Overflow/Underflow SSL1
An rvalue of floating point type can be Conversion from floating point
converted to an rvalue of an integer type. type to integer type are subject
The conversion truncates; that is, the to under/overflow checking.
fractional part is discarded. The behavior LSR-303-2, LSR-303-3
is undefined if the truncated value
cannot be represented in the destination
type.
LSR-403-1-13 5 §5 [expr] LSR-303-4 SSL1
(p. 63) If during the evaluation of an expression,
the result is not mathematically defined
or not in the range of representable
values for its type, the behavior is
undefined.
LSR-403-1-14 5.2.2 §1 [expr.call] Most compilers SSL4
(p. 66) Calling a function through an expression generate correct
whose function type has a language codes for these
linkage that is different from the constructs.
language linkage of the function type of
the called function’s definition is
undefined (7.5)
LSR-403-1-15 5.2.2 §7 [expr.call] Most compilers SSL4
(p. 67) When there is no parameter for a given generate correct
argument, the argument is passed in such codes for these
a way that the receiving function can constructs.
obtain the value of the argument by
involving va_arg (18.7)…
If the argument has a non-POD class
type (clause 9), the behavior is
undefined.
3-51
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1-16 5.2.7 §8 [expr.dynamic.cast] Correct dynamic cast SSL1
(p. 70) The run-time check logically executes as
follows:
-…
-…
- Otherwise, the run-time check fails.
The value of a failed cast to pointer type
is the null pointer result value of the
required result type. A failed cast to
reference type throws bad_cast (18.5.2).
LSR-403-1-17 5.2.8 §2 [expr.typeid] Correct typeid argument SSL1
(p. 71) If the lvalue expression is obtained by
applying the unary * operator to a
pointer and the pointer is a null pointer
value (4.10), the typeid expression
throws the bad_typeid exception
(18.5.3).
LSR-403-1-18 [expr.static.cast] This problem is not dealt with SSL2
An lvalue of type “cv1 B” , where B is a directly using a check at the
5.2.9 §5 class type, can be cast to type “reference time of the cast. The execution
(p. 72) to cv2 D” , where D is a class derived is pursued and the result of the
(clause 10) from B, … cast is therefore checked.
Otherwise, the result of the cast is
undefined.
LSR-403-1-19 5.2.9 §8 [expr.static.cast] This problem is not dealt with SSL2
(p. 73) An rvalue of type “pointer to cv1 B”, directly using a check at the
where B is a class type, can be converted time of the cast. The execution
to and rvalue of type “pointer to cv2 is pursued and the result of the
D”… cast is therefore checked.
Otherwise, the result of the cast is
undefined.
LSR-403-1-20 5.2.9 §9 [expr.static.cast] This problem is not dealt with SSL2
(p. 73) If class B contains the original member, directly using a check at the
or is a base or derived class of the class time of the cast. The execution
containing the original member, the is pursued and the result of the
resulting pointer to member points to the cast is therefore checked.
original member. Otherwise, the result
of the cast is undefined.
LSR-403-1-21 5.2.10 §6 [expr.reinterpret.cast] Function pointer must point to SSL1
(p. 73) A pointer to a function can be explicitly a valid function
converted to a pointer to a function of a LSR-303-9
different type. The effect of calling a
function through a pointer to a function
type (8.3.5) that is not the same as the
type used in the definition of the
function is undefined.
LSR-403-1-22 NA A pointer to a function is converted to a Pointer within bounds SSL1
pointer to an object. LSR-303-10
3-52
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1-23 NA A pointer to an object is converted to a SSL1
pointer to a function. Pointer within bounds
LSR-303-11
LSR-403-1-24 5.2.11 §7 [expr.const.cast] SSL4
(p. 75) Depending on the type of the object, a
write operation through the pointer,
lvalue, or pointer to data member
resulting from a const_cast that casts
away a const-qualifier may produce
undefined behavior (7.1.5.1)
LSR-403-1-25 5.3.4 §6 [expr.new] Strictly positive array size SSL1
(p. 79) If n is negative, the effect of new Extended to all dynamically
float[n][5] is undefined. allocated arrays.
LSR-403-1-26 5.3.5 §3 [expr.delete] Compatible dynamic type. SSL4
(p.81) In the first alternative (delete object), if The dynamic object type of the
the static type of the operand is different operand of delete must be
from its dynamic type, the static type checked.
shall be a base class of the operand’s
dynamic type and the static type shall
have a virtual destructor or the behavior
is undefined.
LSR-403-1-27 5.3.5 §3 [expr.delete] Compatible dynamic type SSL4
(p.81) In the second alternative (delete array) if The dynamic object type of the
the dynamic type of the object to be operand of delete [] must be
deleted differs from its static type, the checked.
behavior is undefined
LSR-403-1-28 5.3.5 §4 [expr.delete] SSL4
(p.81) The value of a pointer that refers to de-
allocated storage is indeterminate.
LSR-403-1-29 5.5 §4 [expr.mptr.oper] SSL1
(p.83) If the dynamic type of the object does Correct pointer to member
not contain the member to which the function
pointer refers, the behavior is undefined.
.* and ->*
LSR-403-1-30 5.5 §6 [expr.mptr.oper] Correct pointer to member SSL1
(p.83) If the second operand is the null pointer function
to member value (4.11), the behavior is
undefined. .* and ->*
LSR-403-1-31 5.6 §4 (p.84) [expr.mul] Division by zero SSL1
If the second operator of / or % is zero LSR-303-4
LSR-403-1-32 5.7 §5 [expr.add] Pointer within bounds SSL1
(p. 84) If both the pointer operand and the result When an expression that has
point to elements of the same array integral type is added to or
object, or one past the last element of the subtracted from a pointer.
array object, the evaluation shall not LSR-303-13
produce an overflow; otherwise, the
behavior is undefined.
3-53
14882:1998 14882 :1998 Consequences
Sections
(p. 84) As with any other arithmetic overflow, if Two pointers to elements of
the result does not fit the space provided, the same array object are
the behavior is undefined. subtracted.
LSR-303-13
(p. 85) Unless both pointers point to elements of Two pointers to elements of
the same array object, or one passes the the same array object are
last element of the array object, the subtracted.
behavior is undefined. LSR-303-13
LSR-403-1-35 5.8 §1 [expr.shift] Shift amount in … In the second case it SSL1
(p. 85) The shift operators << and >> group left- Left shift … amounts to a form of
to-right. … LSR-303-14 overflow.
The behavior is undefined if the right
operand is negative, or greater than or
equal to the length in bits of the
promoted left operand.
LSR-403-1-36 6.6.3 §2 [stmt.return] Function does not raise an SSL1
(p. 98) Flowing off the end of a function is exception
equivalent to a return with no value; this Function returns a value or
result is undefined behavior in a value- raises an exception
returning function.
LSR-403-1-37 7.1.5.1 §4 (p. [dcl.type.cv] SSL4
107) Except that any class member declared
mutable (7.1.1) can be modified, any
attempt to modify a const object during
its lifetime (3.8) results in undefined
behavior.
LSR-403-1-38 7.1.5.1 §7 (p. [dcl.type.cv] SSL4
108) If an attempt is made to refer to an
object defined with a volatile-qualified
type through the use of an lvalue with a
non-volatile-qualified type, the program
LSR-403-1-39 8.5 §9 [dcl.init] Non-initialized variable. SSL1
(p. 142) If no initializer is specified for an object,
the object and its sub-objects, if any,
have an indeterminate initial value.
LSR-403-1-40 9.3.1 §1 [class.mfct.nonstatic] Non-null receiver. SSL1
(p. 154) If a non-static member function of a Correct type for receiver.
class X is called for an object that is not
of type X, or of a type derived from X,
3-54
14882:1998 14882 :1998 Consequences
Sections
LSR-403-1-41 10.4 §6 [class.abstract] Virtual call not pure SSL1
(p. 173) Member functions can be called from a
constructor (or destructor) of an abstract
class; the effect of making a virtual call
(10.3) to a pure virtual function directly
or indirectly for the object being created
(or destroyed) from such a constructor
(or destructor) is undefined.
LSR-403-1-42 12.4 §12 [class.dtor] SSL1
(p. 192) …, if the object is not of the destructor’s Correct type of receiver.
class type and not of a class derived
from the destructor’s class type, the
program has undefined behavior
LSR-403-1-43 12.4 §14 [class.dtor] For example, if the destructor SSL4
(p. 193) Once a destructor is invoked for an for an automatic object is
object, the object no longer exists; the explicitly invoked, and the
behavior is undefined if the destructor is block is subsequently left in a
invoked for an object whose lifetime has manner that would ordinarily
ended (3.8). invoke implicit destruction of
the object, the behavior is
undefined.
LSR-403-1-44 12.5 105) [class.free] SSL4
(p. 193) If the static type in the delete-expression
is different from the dynamic type and
the destructor is not virtual the size
might be incorrect, but that case is
already undefined; see 5.3.5.
LSR-403-1-45 15.3 §17 [except.handle] Function returns a value or SSL1
(p. 295) Flowing off the end of a function-try- raises an exception.
block is equivalent to a return
With no value, this result is undefined
behavior in a value-returning function
(6.6.3).
3-55
Table 6 Applicable Checks for C++ Polyspace Code Prover (C++ libraries)
Requ. ISO/IEC Description in ISO/IEC Details Typical Run-Time SSL
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-1 17.1.15 defns.required.behavior SSL4
(p. 312) If a function defined in a C++ program
fails to meet the required behavior when
it executes, the behavior is undefined.
LSR-403-2-2 17.1.17 defns.reserved.function SSL4
(p. 313) If a C++ program provides a definition
for any reserved function, the results are
undefined.
LSR-403-2-3 17.4.3.1 §1 lib.reserved.names SSL4
(p. 321) It is undefined for a C++ program to add
declarations or definitions to namespace
std or namespaces within namespace std
unless otherwise specified.
(p. 321) A program may add template
specializations for any standard library
template to namespace std. Such a
specialization (complete or partial) of a
standard library template results in
undefined behavior unless the
declaration depends on a user-defined
name of external linkage and unless the
specialization meets the standard library
requirements for the original template.
(p. 321) If the program declares or defines a
name in a context where it is reserved,
other than as explicitly allowed by this
clause, the behavior is undefined.
LSR-403-2-6 17.4.3.2 §1 [ib.alt.reserved] SSL4
(p. 322) If a file with a name equivalent to the
derived file name for one of the C++
Standard Library headers is not provided
as part of the implementation, and if a
file whose name is placed in any of the
standard places for a source file to be
included (16.2), the behavior is
undefined.
LSR-403-2-7 17.4.3.2 §2 [lib.res.on.functions] SSL4
(p. 323) In particular, effects are undefined in the
following cases:
for replacement functions …
for handler functions …
for types used as template arguments …
if any replacement function …
if any incomplete type
3-56
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-8 17.4.3.7 lib.res.on.arguments LSR-303-18 SSL2
(p. 324) Each of the following statements applies LSR-303-22
to all arguments for functions defined in
the C++ Standard Library, unless
explicitly stated otherwise.
If an argument to a function has an
invalid type (such as a value outside the
domain of the function, or a pointer
invalid for its intended use), the behavior
is undefined.
LSR-403-2-9 17.4.3.8 lib.res.on.required Illegal exception thrown SSL1
(p. 324) Violation of the preconditions specified A run-time verification of the
in a function’s Required behavior exception potentially thrown
section results in undefined behavior w.r.t to the declared one must
unless the function’s Throws section be performed.
specifies throwing an exception when
the precondition is violated.
LSR-403-2-10 18.1 lib.support.types SSL4
(p. 328) The result of applying the offset of
macro to a field that is a static data
member or a function member is
undefined.
LSR-403-2-11 18.7 §3 lib.support.runtime SSL4
(p. 347) The parameter paramN is the identifier
of the rightmost parameter in the
variable parameter list of the function
definition (the one just before …). If the
parameter paramN is declared with a
function, array, or reference type, or
with a type that is not compatible with
the type that results when passing an
argument for which there is no
parameter, the behavior is undefined. (cf
ISO C subclause 4.8.1.1).
LSR-403-2-12 18.7 §4 lib.support.runtime SSL4
(p. 347) If any automatic objects would be
destroyed by a thrown exception
transferring control to another
(destination) point in the program, then a
call to longjmp(jbuf,val) at the throw
point that transfers control to the same
(destination) point has undefined
behavior.
LSR-403-2-13 19.1.1 §1 [lib.logic.error] Logic error not raised SSL1
(p. 349) The class logic_error defines the type of (warning)
objects thrown as exceptions to report
errors presumably detectable before the
program executes, such as violations of
logical preconditions or class invariants.
3-57
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-14 19.1.6 §1 [lib.runtime.error] Run-time error not raised SSL1
(p. 351) The class runtime_error defines the type (warning)
of objects thrown as exceptions to report
errors presumably detectable only when
the program executes.
LSR-403-2-15 20.4.5 §3 [lib.auto.ptr] SSL4
(p. 373) If more than one auto_ptr owns the same
object at the same time, the behavior of
the program is undefined.
LSR-403-2-16 20.4.5 §3 [lib.auto.ptr] SSL4
(p. 373) Initiating a Standard Library container
with an auto_ptr results in undefined
behavior.
LSR-403-2-17 [lib.string.access] Assert SSL1
21.3.4 §1 operator [] (size_type pos)
(p. 391) Otherwise ( pos > size()), the behavior is
undefined.
LSR-403-2-18 23.2.2.4 §12 [lib.list.ops] Limitation SSL4
(p. 478) The result is undefined if position is an
iterator in the range [first,last].
LSR-403-2-19 24.1 §5 [lib.iterator.requirements] SSL4
(p. 510) Results of most expressions are
undefined for singular values.
LSR-403-2-20 24.1 §5 [lib.iterator.requirements] Limitation SSL4
(p. 510) The result of the application of functions
in the library to invalid ranges is
undefined.
LSR-403-2-21 24.5.3 §2 [lib.istreambuf.iterator] SSL4
(p. 532) The result of operator*() on an end of
stream is undefined.
LSR-403-2-22 26.1 §2 [lib.numeric.requirements] SSL4
(p. 566) If any operation on T throws an
exception, the effects are undefined.
LSR-403-2-23 26.2 §3 [lib.complex.numbers] Limitation SSL4
(p. 566) If the result of a function is not
mathematically defined or not in the
range of representable values of its type,
LSR-403-2-24 26.3.2.1 §4 lib.valarray.cons Assert SSL1
(p. 579) valarray (const T*,size_t)
If the value of the second argument is
greater than the number of values
pointed to by the first argument, the
LSR-403-2-25 26.3.2.2 §1 lib.valarray.assign Assert SSL1
(p. 579) valarray<T>&operator=(const
valarray<T>&)
The resulting behavior is undefined if
the length of the argument array is not
equal to the length of the *this array.
3-58
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-26 26.3.2.2 §4 lib.valarray.assign SSL4
(p. 579) If the value of an element in the left
hand side of a valarray assignment
operator depends on the value of another
element in that left hand side, the
resulting behavior is undefined.
LSR-403-2-27 26.3.2.3 §6 lib.valarray.access Assert SSL1
(p. 580) T operator[] (size_t) const;
T& operator[] (size_t);
If the subscript operator is invoked with
a size_t argument whose value is not
less than the length of the array, the
LSR-403-2-28 26.3.2.6 §3 lib.valarray.cassign Assert SSL1
(p. 581) If the array and the argument array do
not have the same length, the behavior is
undefined.
LSR-403-2-29 26.3.2.6 §4 lib.valarray.cassign SSL4
(p. 581) If the value of an element in the left-
hand side of a valarray computed
assignment operator depends on the
value of another element in that left-
hand side, the resulting behavior is
undefined.
LSR-403-2-30 26.3.2.7 §2 lib.valarray.members Assert SSL1
(p. 581) T sum() const;
If the array has length 0, the behavior is
undefined.
LSR-403-2-31 26.3.2.7 §3 [lib.valarray.members] Assert SSL1
(p. 582) T min const ;
This function returns the minimum value
contained in *this. The value returned
for an array of length 0 is undefined.
LSR-403-2-32 26.3.2.7 §4 [lib.valarray.members] Assert SSL1
(p. 582) T max const ;
This function returns the maximum
value contained in *this. The value
returned for an array of length 0 is
undefined.
LSR-403-2-33 26.3.3.1 §3 lib.valarray.binary Assert SSL1
(p. 583) valarray binary operators
If the argument arrays do not have the
same length, the behavior is undefined.
LSR-403-2-34 26.3.3.2 §3 lib.valarray.comparison Assert SSL1
(p. 584) valarray logical operators
If the two array arguments do not have
the same length, the behavior is
undefined.
3-59
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-35 26.3.6 §6 lib.class.gslice SSL4
(p. 588) If a degenerate slice is used as the
argument to the non-const version of
operator[] (const gslice&), the resulting
LSR-403-2-36 26.3.9.2 §2 lib.indirect.array.assign SSL4
(p. 593) If the indirect_array specifies an element
in the valarray<T> object to which it
refers more than once, the behavior is
undefined.
LSR-403-2-37 26.3.9.3 §2 lib.indirect.array.comp.assign SSL4
(p. 593) If the indirect_array specifies an
element in the valarray<T> object to
which it refers more than once, the
LSR-403-2-38 27.1.1 [lib.iostreams.limits.inbue] SSL4
(p. 599) If any user function called from a
function declared in clause 27 or as an
overriding virtual function of any class
declared in clause 27 calls inbue, the
LSR-403-2-39 27.4.2.7 §1 [lib.ios.base.cons] SSL4
(.p 612) Each ios_base member has an
indeterminate value after construction.
LSR-403-2-40 27.4.3.2 §2 Lib.fpos.operations SSL4
(p. 613) Stream operations that return a value of
type traits::pos_type return P(O(-1)) as
an invalid value to signal an error. If this
value is used as an argument to any
istream, ostream, or streambuf member
that accepts a value of type
traits::pos_type then the behavior of that
function is undefined.
LSR-403-2-41 27.4.4.1 §2 [lib.basic.ios.cons] SSL4
(p. 614) The object must be initialized by calling
its init function member function. It is
destroyed before it has been initialized
LSR-403-2-42 27.7.1.3 §14 [lib.stringbuf.virtuals] SSL4
(p. 652) If sp has not been obtained by a previous
successful call to one of the positioning
functions (seekoff, seekpos,tellg,tellp),
the effect is undefined.
LSR-403-2-43 27.8.1.1 §4 [lib.filebuf] SSL4
(p. 658) An instance of basic_filebuf behaves as
described in 27.8.1.1, provided
traits::pos_type is
fops<traits::state_type>. Otherwise the
3-60
14882:1998 14882 :1998 Consequences
Sections
LSR-403-2-44 27.8.1.4 §14 [lib.filebuf.virtuals] SSL4
(p. 662) If sp has not been obtained by a previous
successful call to one of the positioning
functions (seekoff, seekpos) on the same
file, the effects are undefined.
LSR-403-2-44 D.7.1 §4 [depr.strstreambuf] SSL4
(p. 704) If gnext is a null pointer, the seekable
area is undefined.
D.5 §1. (p.701)
For compatibility with the Standard C library, the C++ Standard library provides the 18 C
headers.
<assert.h> <iso646.h> <setjmp.h> <stdio.h> <wchar.h>

<ctype.h> <limits.h> <signal.h> <stdlib.h> <wctype.h>
<errno.h> <locale.h> <stdarg.h> <string.h>
<float.h> <math.h> <stddef.h> <time.h>
3-61
Table 7 Applicable checks for C++ Polyspace Code Prover (C library)
ISO/IEC SSL
9899:1990 Description in ISO/IEC Typical Run-Time
Requ. Sections 9899:1990 Details Consequences
LSR-403-3-1 NA The value of the object allocated by This is the non-initialized Implementations of SSL1
the malloc() function is used before a variable problem in the case of malloc do not initialize
value is assigned dynamically allocated objects. the memory blocks.
LSR-303-16 Unpredictable behavior
can ensue.
LSR-403-3-2 7.1.7, 7.2, 7.3, A library function argument has an Includes null pointers and out- Memory corruption, SSL2
7.4, 7.5, 7.6, invalid value, sub case: pointer of-bounds pointers passed to unpredictable behavior,
7.7, 7.8, 7.9, arguments frexp(), modf() and to all other or crash often occurs
7.10, 7.11, functions of Sections 7.2 to 7.12 when these functions
7.12, G.2 (p. with pointer parameters are applied to out-of-
202) (stdio.h, stdlib.h, string.h, bounds or null pointers.
time.h, …)
LSR-303-18
LSR-403-3-3 7.2.1.1 The assert(int expr) macro puts This is a debugging and testing Used during tests and SSL1
diagnostics into programs. When it is facility for which Polyspace disabled in production.
executed, if expr evaluates to false Code Prover shall generate a
(…) then the assert macro writes check indicating the failure
information about the particular call status of the corresponding
that failed (…) it then calls abort. assertion. It can also be used to:
(1) ask Polyspace Code Prover
to prove that a particular
property is always true; (2)
assume that a particular
property holds (in particular to
take into account system-level
properties).
LSR-303-19
LSR-403-3-4 7.3 An argument to a character-handling Example erroneous call: Memory corruption, SSL2
function is out of the domain isalpha(0xfffff) unpredictable behavior,
(ctype.h) LSR-303-20 or crash often occurs
when these functions
are applied to values
outside the range of
EOF, 0..UCHAR_MAX
LSR-403-3-5 7.4 The locale.h library. No checks and undefined SSL2
behavior besides those
described in LSR-303-18
LSR-303-21
LSR-403-3-6 7.5 For all functions, a domain error Relevant functions: acos(), In implementations, an SSL2
occurs if an input argument is asin(), atan2(), log(), log10(), IEEE748 NaN or
outside the domain over which the pow(), sqrt(), fmod(). Semantic exception will be
mathematical function is defined. model required: exception generated.
generation on domain error.
LSR-303-22
3-62
ISO/IEC SSL
9899:1990 Description in ISO/IEC Typical Run-Time
Requ. Sections 9899:1990 Details Consequences
LSR-403-3-7 7.5 A range error occurs if the result of Relevant functions: tan(), In implementations, an SSL2
the [mathematical] function cannot cosh(), sinh(), exp(), ldexp(), IEEE748 infinity or
be represented as a double. log(), pow(). Semantic model overflow exception will
required: exception generation be generated.
on range error instead of
infinity (HUGE_VAL)
generation.
LSR-303-23
LSR-403-3-8 7.6 Non-local jumps: the setjmp() and Required Polyspace Code SSL4
longjmp() functions. Prover support: assume that
these functions have no effect.
LSR-303-24
LSR-403-3-9 7.7 The signal() and raise() functions. Required Polyspace Code SSL4
Prover support: assume that
these functions have no effect.
LSR-303-25
LSR-403-3-10 7.8 The varargs.h library. LSR-303-26 SSL2
LSR-403-3-11 7.9 The stdio.h library. LSR-303-27 SSL2
LSR-403-3-12 7.10 The stdlib.h library. LSR-303-28 SSL2
LSR-403-3-13 7.11 The string.h library. LSR-303-29 SSL2
LSR-403-3-14 7.12 The time.h library. LSR-303-30 SSL2
3-63
3.5 Traceability Matrix HLR/OR and LSR
For traceability between the High-Level Requirements (HLRs), Operational Requirements

(ORs) and Language Specific Requirements (LSRs), please refer to:
3-64
3.6 Polyspace Products for C++ Appendixes
3.6.1 Description of Call-Graph File
The first line contains the legend of fields used by data table (described in the next section).
The call tree description begins with the main subprogram, and follow lines that reproduce Call
Tree.
The function calls from main occur in the same order as in the application.
Depth of call is given by the number of | characters before the > or -> symbols (for example |
| | -> means a depth of 3 calls from the main function) . Differences between terminal
calls (subprograms that do not call any subprogram) and non-terminal calls are indicated by >
for terminal calls and -> for the others.
Particular cases of indirect recursion calls are printed as follows : | | … | **

RecursiveCall: which indicates the other function of the indirect recursion.
The lines fields are separated by a tabulation character (\t UNIX code). For fields detailed
descriptions, see Section 3.6.1.2.
When a function calls a function that has already been called, the corresponding call-graph part
is not repeated. Instead, only a message already displayed above is printed.

Call tree:
Contains the name of the called function, the depth of the function call from the main, and the
case of terminating or non-terminating call.
The format is :
| | | … | - > [package|file].FunctionName
or
| | | … | ** RecursiveCall: [package|file].FunctionName
3-65
Appears in each line representing a call.
File:
Contains the localization (file name) of a function call.
Line:
Contains the localization (line number) of a function call.
Col:
Contains the localization (column number) of a function call.
3.6.1.3 Example
Following is an example of a call tree in Excel file format from our tests set application.
Call tree File Line Col Tasks

CSPF.main
| > ELA_POS_VIT_AC._init_globals CSPF.c 234 5
| > pst_stubs_0.init_log_cspf CSPF.c 241 8
| > pst_stubs_0.init_log_acq_etors_cssol CSPF.c 242 8
| > pst_stubs_0.init_log_ela_pos_vit_ac CSPF.c 243 8
| > pst_stubs_0.init_log_gerer_id_cd CSPF.c 244 8
| > pst_stubs_0.init_log_com_stors CSPF.c 245 8
| > pst_stubs_0.init_log_inf_constituants CSPF.c 246 8
| > pst_stubs_0.init_bou_cspf CSPF.c 254 8
| > pst_stubs_0.init_bou_acq_etors_cssol CSPF.c 255 8
| > pst_stubs_0.init_bou_ela_pos_vit_ac CSPF.c 256 8
| > pst_stubs_0.init_bou_gerer_id_cd CSPF.c 257 8
| > pst_stubs_0.init_bou_com_stors CSPF.c 258 8
| > pst_stubs_0.init_bou_inf_constituants CSPF.c 259 8
| - > ACQ_ETORS_CSSOL.acq_etors_cssol CSPF.c 264 4
| | - > DET_CONF_PF.det_conf_pf ACQ_ETORS_CSSOL.c 187 4
| | | > VOTE_2_3.vote_2_3_bord_1 DET_CONF_PF.c 392 15
3-66
| | > MODE_PF.mode_pf ACQ_ETORS_CSSOL.c 189 4
| | - > ACQ_MESS_CSSOL_CSPF.acq_mess_cssol_cspf ACQ_ETORS_CSSOL.c 191 4
| | | > CALCUL_CRC_32.calcul_crc_bord_1 ACQ_MESS_CSSOL_CSPF.c 215 27
| | - > VER_MESS_CSSOL_CSPF.ver_mess_cssol_cspf ACQ_ETORS_CSSOL.c 193 4
| | | > CSPF.trap1 VER_MESS_CSSOL_CSPF.c 400 16
| | | - > TRAME_CSG.decompactage_trame_csg_bord_1 VER_MESS_CSSOL_CSPF.c 494 4
| | | | > TRAME_CSG.recopie_buffer_bord_1 TRAME_CSG.c 725 29
| | | | - > TRAME_CSG.decompacte_mottor_bord_1 TRAME_CSG.c 735 27
| | | | | > pst_stubs_0.random_octet TRAME_CSG.c 383 29
| | > DET_CONF_BASSIN.det_conf_bassin ACQ_ETORS_CSSOL.c 195 4
| - > ELA_POS_VIT_AC.ela_pos_vit_ac CSPF.c 267 4
| | > RECALAGE.recalage ELA_POS_VIT_AC.c 751 4
| | > ETALONNAGE.etalonnage ELA_POS_VIT_AC.c 753 4
| | - > ELA_POSITION.ela_position ELA_POS_VIT_AC.c 755 4
| | | > MEDIANE.mediane_reel_bord_1 ELA_POSITION.c 410 18
| | | > __polyspace__stdstubs.fabs ELA_POSITION.c 428 41
| | > ELA_VIT_ACC.ela_vit_acc ELA_POS_VIT_AC.c 757 4
| - > GERER_ID_CD.gerer_id_cd CSPF.c 270 4
3.6.2 Description of Data-Table File

The first line contains the legend of fields used by data table (described in the next section). The
second line contains only the application name, and this line starts with a “-“.
The data table opens:
For each global variable, one line containing its characteristics (type, value, …) is printed.
Further on in this document, this line will be called CL (characteristics line). These lines begin
with a pattern of the form | - or like | | | … | - for sub-fields of global
variables.
If the global variable is read or written, for each access to it an access line (AL) is printed above
the CL. Lines begin with a pattern of the form | < (write access) or
| > (read access), and with a pattern | | … | > (read access) or | | …

| < (write access) for global variables sub-fields.
3-67
For each global variable, accesses are sorted by type (read or write, write accesses are printed
first, and then read accesses), and accesses are printed until a new CL is encountered.
To make it easier to extract information from this file, fields of both CL and AL are separated by
a tabulation character (\t). Fields are described in the following section.
At the end of the data table, an Excel file appears with a section called legend which links
between task acronyms found in field W.T. (like t[0-9]) and tasks obtained by -tasks option.

Variables:
Contains the name of global variables.
The format is:
[Package|File].VarName[.subfield1 [.subfield2[…]]]
W.T: (written by tasks)

Contains the descriptor of tasks defined by -entry-points which write the global variable
(the mapping between task names from -entry-points and task descriptors is available at
the end of the Excel file)).
The format is:
[t1[,t2[,…]]]
R.T: (read by tasks)

Contains the name of the tasks reading the global variable.
The format is:
[task1[,task2[…]]]
3-68
where task1, task2 are tasks given as parameter to the -entry-points option
This field is empty if the global variable is not read by a task.
Protection:
Contains protection(s) used for protection of global shared variables.
 Critical section – if task access is protected by critical sections

 Access pattern – if task access is protected by access patterns
 Temporal exclusion – if task access is protected by temporal exclusion
 Null – if no protection is applied to the shared variable
The format is:
[Critical section[,…]]
Usage:
Contains usage of global variables.
 readNOTw – If the variable is read but not written

 aliased – If the variable is aliased
 shared – If the variable is shared by tasks
The format is:
This field is empty if no specific usage is done for global variables.
3-69
Scal:
Contains the answer to the question Is the variable a scalar ?.
 Yes – If the variable is a scalar one

 Empty – If no information is provided about the variable
Line:
Contains the localization (line number) of an access to a variable.
Col:
Contains the localization (column number) of an access to a variable.
File:
Contains the localization (file name) of an access to a variable.
Detailed value:
Provides the type definition of the global variable.
This type is the type provided at variable declaration.
Value:
Provides all the values that a global variable can reach during execution, given as a
disjunction of intervals.
This field is empty if no value was computed by Polyspace Code Prover.
Potential:
Provided the information about potential access (in C only, due to pointer analysis).
3-70
 Is potential – If the access is potential

 Empty – If the access is certain
3.6.2.3 Example
Here is an example of a Data Dictionary in Excel file format from our tests set application.
Variables W.T R.T Protection Usage Scal Line Col File Detailed Type Value Potential
-TCTM_O0
| -BM_ABS_REC_CSSOL_EN_OPERATIONNEL_1 0..255
| | < VER_MESS_CSSOL_CSPF.ver_mess_cssol_cspf 398 16 VER_MESS_CSSOL_CSPF.c
| -BM_CD8_N_1 0..255
| | < STOP_PF_CHGT_DCHGT.stop_pf_chgt_dchgt 322 4 STOP_PF_CHGT_DCHGT.c
| | > STOP_PF_CHGT_DCHGT.stop_pf_chgt_dchgt 211 18 STOP_PF_CHGT_DCHGT.c
| -BM_CD8_S_1 0..255
| | < STOP_PF_CHGT_DCHGT.stop_pf_chgt_dchgt 323 4 STOP_PF_CHGT_DCHGT.c
| -BM_DEMANDE_ECRITURE_COEF_EN_EEPROM_1 0..255
| | < ELA_POS_VIT_AC.ecrire_coef_eeprom_bou 637 12 ELA_POS_VIT_AC.c
| | < ETALONNAGE.etalonnage 313 12 ETALONNAGE.c
| | > ELA_POS_VIT_AC.ecrire_coef_eeprom_bou 599 7 ELA_POS_VIT_AC.c
| | > ETALONNAGE.etalonnage 247 12 ETALONNAGE.c
| -BM_DEMANDE_ECRITURE_OFF_EN_EEPROM_1 0..255
| | < ELA_POS_VIT_AC.ecrire_off_eeprom_bou 531 12 ELA_POS_VIT_AC.c
| | < RECALAGE.recalage 157 8 RECALAGE.c
| | > ELA_POS_VIT_AC.ecrire_off_eeprom_bou 493 7 ELA_POS_VIT_AC.c
| | > RECALAGE.recalage 154 8 RECALAGE.c
| -BM_DEUX_MESS_REC_OK_DU_CSSOL_1 0..255
| | < VER_MESS_CSSOL_CSPF.ver_mess_cssol_cspf 472 12 VER_MESS_CSSOL_CSPF.c
| | > AUT_MVT_PF.aut_mvt_pf 223 9 AUT_MVT_PF.c
| | > MOT_ID_MOT_CD.mot_id_mot_cd 227 7 MOT_ID_MOT_CD.c
3-71
3.6.3 JSF++ Rules
3.6.4 Warning/Error Messages Format In The Log File

Warning and error messages given by Polyspace in the log file have the format defined as:
$FILE, line $line (column $col): type: message
 “column” is optional
Example. $FILE, line $line: type: message
 “line” is optional
Example. $FILE: type: message
 “file” (optional) is the fullpath of the involved file.
Example. type: message
 type=[error|remark|warning|catastrophic error|internal error|
link error|command line error|limitation| User Program Error]
Type is not case sensitive
 The message can be on several lines, each new line must start with ‘|’
$FILE, line $line (column $col): type: message_11
| message_12
| message_13
3.6.5 Description of PSCP file

The first line contains the legend of fields used by PSCP file.
The second line contains the application name and the summary of the checks numbers for the
application. This line starts with a “-“.
The PSCP file:

For each package, file, subprogram or check (called item in the following section ), one line
containing its characteristics (color, line, column…) is printed. Further on in this document, this
line will be called CL (characteristics line). These lines begin with a pattern of the form | -
or like | | | … | - for sub-fields.
3-72
If the CL describes a package, file or subprogram, it will begin with a pattern of the form | |
-
If the CL describes a check, it will begin with a marker that indicates the color of the check:
 V indicates that a check is an impossible error

 ? indicates that a check is a possible error
 X indicates that a branch is unreachable
 ! indicates that a check is a certain error
In order to make the information easier to extract from this file, fields are separated by a
tabulation character (\t). Fields are described in the following section.
At the end of the PSCP file, there is a section called LIST OF CODE PROVER OPTIONS
which gives options used for the verification.

Procedural entities
This view contains a tree structure
 The first level of the tree displays:

- In C language: source files (.c files)
- In C++ language: source files (.cpp files)
 Others levels of the tree display:
- In C language: functions or checks found in analyzed source code
- In C++ language: functions and methods or checks found in analyzed source code
R
Indicates the number of red checks (certain errors) in the package, file or subprogram, or if a
check is a certain error
O
Indicates the number of orange checks (possible errors in the package, file or subprogram, or if a
check is a possible error)
3-73
Gy
Indicates the number of unreachable branches in the package, file or subprogram
Gn
Indicates the number of green checks (error does not occur) in the package, file or subprogram,
or if a check is an impossible error
Line
Contains the localization (line number) of the item
Col
Contains the localization (column number) of the item
%
Indicates the selectivity rate of each subprogram, package, or file.
Selectivity rate is given by the ratio: all checks except orange ones / total checks number:
Number of (green checks + red checks) .

Number of (green checks + red checks + orange checks)
Note - Dark orange checks are considered as orange checks.
Details
Gives the explanation of the check given, if one exists.
Macro Code
Internal code that represents the check type and its color
Reviewed
Indicates if the item is reviewed or not. A reviewed item is indicated by an “X” character.
Comment
Displays the comment given for an item using the the Polyspace environment.
Scalar/Float
Contains the answer to the question Is the check a scalar?
 Scalar – if the check is a scalar one
 Float – if the check is a float one
 Empty – if no information is provided
3-74
Location file
Contains the localization (file name) of the item
Context
Gives the contextual orange value of the check if provided
3.6.6 MISRA C++ Rules

3-75
3-76
4 Polyspace Code Prover User
Information
User information for Polyspace Code Prover is available at the MathWorks Documentation
Center, R2015a.
4-2
5 Installation
To use the Polyspace Code Prover product, install the following MathWorks® products:
 MATLAB®
 Polyspace® Bug Finder™
 Polyspace Code Prover
Instructions for installing the products are in the MathWorks® Documentation Center, R2015a:
Installation
5-2
6 Operational Environment
The DO Qualification Kit product supports the following operating environments for the
Polyspace Code Prover product:
 Personal computer
 One of the following operating systems:
 Microsoft® Windows®
 Linux®2
 MATLAB® Software
 Polyspace Bug Finder software
 Polyspace Code Prover software
2
Linux® is a registered trademark of Linus Torvalds.
6-2
7 References
7.1 Applicable Documents for C
Floating point arithmetic standard IEEE 748
Programming languages – C. International standard ISO/EIC 9899: 1990 (E)
Polyspace Code Prover High-level Specifications version 1.8, September 2004
IEEE Standard 754 Floating Point Number
Polyspace Automatic Tests Tool Operational Requirements Specification (OPREQS-CI)
HIS (Hersteller Initiative Software) Source Code Metrics, version 1.3.1, 2008
7-2
7.2 Applicable Documents for C++
Floating point arithmetic standard IEEE 748
Programming languages – C++. International standard ISO/EIC 14882: 1998 (E)
Programming languages – C. International standard ISO/EIC 9899: 1990 (E)
Polyspace Code Prover High-level Specifications version 1.9
Polyspace Operational Requirements Validation Plan version 1.4
Polyspace C++ Operational Requirements Validation Plan version 1.6
7-3
7.3 Applicable Rules for C and C++
7.3.1 Polyspace Custom Rules
7-4
8 Definitions and Abbreviations
8.1 Abbreviations
OR Operational Requirement
NaN Not a Number
LSR Language Specific Requirement
HLR High-Level Requirement
NTL Non-Terminating Loop
NTC Non-Terminating Call
SSL Semantic Support Level
BTV Base de Tests de Validation
(Polyspace Technologies test environment)
QA Quality Assurance
8-2

Qualkitdo Codeprover Tor PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Qualkitdo Codeprover Tor PDF

Uploaded by

Copyright:

Available Formats

DO Qualification Kit

Polyspace® Code Prover™

R2015a, March 2015

The MathWorks, Inc.

DO Qualification Kit: Polyspace® Code Prover™ Tool Operational Requirements

 Proven absence of certain run-time errors in C and C++ code

 General operational requirements (OR), most of which are programming language

 Tool input or semantic requirements

The general classification of ORs is as follows, where xx [0,99]

Polyspace Code Polyspace Code Polyspace

 Using -sources-list-file: each file name needs to be given with an absolute

1 Linux is a registered trademark of Linus Torvalds.

OR-354: Polyspace Code Prover shall accept C language dialects

Example: -sfr-types sfr=8,sfr16=16

A sfr type size must be 8, 16 or 32 bits.

See Keil & IAR Extensions.

OR-383: Polyspace Code Prover shall check custom rules

OR-386: Polyspace Code Prover shall check MISRA AC AGC rules

OR-305: Polyspace Code Prover shall ignore default initializations

OR-307: Polyspace Code Prover shall be more or less restrictive on overflowing

With the option -allow-ptr-arith-on-struct:

 Example with the option -allow-ptr-arith-on-struct: int main()

*(int *) ptr = 10; /* access to z.c, Green IDP */

OR-309: Polyspace Code Prover shall allow incomplete or partial allocation of

With the option -size-in-bytes

OR-310: Polyspace Code Prover shall discard assembler code

OR-313: Polyspace Code Prover shall accept a subset of common C language

- designated initializers (labeling initialized elements)

OR-408: Polyspace Code Prover shall detect overflows on bitwise-not assignments

With the option -div-round-down:

With the option -logical-signed-right-shift:

C language sparc c-167 M68k Powerpc (32) i386

C language hc08 hc12 c18 x86_64

a) Pointers (near or far pointer) can have 2 bytes of width physically.

 The option -default-sign-of-char [signed¦unsigned] allows user to

 Example of the target MC68000

 Example of the target ST 7

extern int gx;

extern int tab[12];

extern enum glob_state *glob_s;

The user application code:

if (rd) s.x = rd;

OR-318: Polyspace Code Prover shall be permissive on link

OR-356: Polyspace Code Prover shall check MISRA-C rules

OR-352: Polyspace Code Prover shall be useable for small applications

int permanent assert

- This option implies -size-in-byte.

2.1.4 Input Requirements for Information

OR-349: Polyspace Code Prover shall display compilation warnings

2.1.5 Input Requirements for Scaling Options

OR-362: Polyspace Code Prover shall allow non-pointer fields of structures to be

OR-363: Polyspace Code Prover shall inline some subprograms

OR-364: Polyspace Code Prover shall increase performances on large applications

2.1.6 Input Requirements for Tasking

OR-358: Polyspace Code Prover shall run analysis on supported OS

OR-366: Polyspace Code Prover shall provide remote analysis

OR-369: Polyspace Code Prover shall operate on a multi-core OS

OR-376: Polyspace Code Prover shall export a verification report

 The option –continue-with-compile-error allows user to continue verification

2.2.2 Output Requirements for Data Dictionaries

OR-404: Polyspace Code Prover shall export range values

OR-406: Polyspace Code Prover shall identify sources of imprecision

OR-407: Polyspace Code Prover shall generate source code metrics

(int ) ptr = 10; /* access to z.c, Green IDP */