Escher Technologies Escher Technologies
Home Products Services Support News Company Contact Associates Publications
Escher Technologies


Perfect Developer - Making software bugs extinct!
 

Perfect Developer conformance with MISRA C guidelines

The Motor Industry Software Reliability Association has defined a set of rules for the use of the C language in safety-critical automotive applications ("Guidelines for the use of the C Language in vehicle based software", ISBN 0 9524156 9 0, April 1998).

Although the guidelines relate to C rather than C++, the rules concern the avoidance of dangerous features of the C language that are mostly also present of C++. For this reason we give the following compliance matrix indicating the compliance of C++ generated by Perfect Developer to the MISRA standard.

The column labelled Req/Adv indicates whether the rule is Required or Advisory; the column labelled Comp indicates whether C++ code generated by Perfect Developer and the run-time library are compliant.

Compliance summary

Required: compliant with 73, not compliant with 10, other 10

Advisory: compliant with 29, not compliant with 4, other 1

Total: compliant with 103, not compliant with 15, other 9

Rule Req/Adv Comp Notes
1 R Y/N Compliance is to the ISO C++ standard instead of the ISO C90 standard
2 A Y
3 A Y Inline assembler is not used
4 A Y Run-time checking may be enabled at build time
5 R Y
6 R Y* Provided the user selects ASCII and not Unicode
7 R Y
8 R Y* Provided the user selects ASCII and not Unicode
9 R Y
10 A Y
11 R N Modern C++ compilers do not limit identifiers to 31 characters
12 A Y
13 A Y The run-time headers declare the appropriate typedefs
14 R Y
15 A Y* Subject to the C++ compiler being used, IEEE double precision is used
16 R Y
17 R Y
18 A Y Perfect does not use unsigned or long literals
19 R Y
20 R Y
21 R Y
22 A Y
23 A Y User-declared global declarations are public by definition in Perfect; however system-generated declarations are declared static wherever possible
24 R Y
25 R Y
26 R Y
27 A Y
28 A Y
29 R Y
30 R Y Provided that verification has been successful
31 R Y
32 R Y
33 R Y* Called class methods may cache the results of computations in internal data variables for subsequent re-use, but such caching affects performance only and not behaviour
34 R N We consider this rule too strict and likely to make code less readable in some cases
35 R Y
36 A Y Expressions involving bitwise operators are not generated
37 R Y See above
38 R Y See above
39 R Y
40 A Y
41 A Y
42 R Y/N Comma operator is only to work around known bugs in certain compilers when generating debug checks
43 R Y
44 A Y
45 R Y* Except that static_cast<T*>(0) is used to create a null pointer
46 R Y
47 A N We regard this rule as unnecessarily strict
48 A Y
49 A Y
50 R N The user is free to test real numbers for equality
51 A Y
52 R Y* Verification will detect most unreachable code
53 R Y
54 R Y
55 A N Exceptionally, a forward jump out of a block to a label just past the end of the block may be generated
56 R N See above
57 R Y
58 R N We regard break as a legitimate way of terminating a loop provided the context is clear. The alternatives involve introducing additional variables, which complicate the code.
59 R Y
60 A N The rationale given for this rule is not relevant to verified code
61 R Y
62 R N The rationale given for this rule is not relevant to verified code
63 A Y
64 R Y
65 R Y
66 A Y
67 A Y
68 R n/a Not applicable to C++
69 R Y
70 R N* Recursion is permitted, provided that appropriate recursion variants are declared.
71 R Y
72 R Y
73 R Y
74 R Y
75 R Y
76 R n/a Not applicable to C++
77 R Y
78 R Y
79 R Y
80 R Y
81 A Y
82 A N
83 R Y
84 R Y
85 A Y
86 A n/a This is the developer's responsibility
87 R Y
88 R Y
89 R Y
90 R N A fixed set of macros is used to generate boilerplate code and optional debug checks
91 R Y
92 A Y
93 A Y
94 R Y
95 R Y
96 R Y
97 A Y
98 R Y
99 R Y Use of pragmas in the run-time library is documented in comments
100 R Y
101 A Y
102 A Y
103 R Y
104 R Y Pointers to functions are not used
105 R Y See above
106 R Y
107 R Y
108 R Y
109 R N Overlapping storage may be allocated if when-clauses are declared, but use of such storage is safe
110 R Y
111 R Y
112 R Y
113 R Y
114 R Y
115 R Y
116 R n/a Responsibility of the developer
117 R Y Provided the library is correctly specified and verification is performed
118 R N Dynamic memory allocation is central to O-O programming (although dynamic memory allocation can be avoided if certain features are not used)
119 R Y
120 R Y
121 R Y
122 R Y Exceptions are used instead
123 R Y
124 R Y/N* stdio.h is used by the run-time library but could be avoided for embedded systems
125 R Y/N* These functions are only called when it is guaranteed that the string can be converted
126 R Y/N* These functions may be used by the run-time library but could be avoided for embedded systems
127 R Y/N* time.h is used by the run-time library but could be avoided for embedded systems

Note: This information is provided in good faith, however Escher Technologies makes no warranty as to its correctness or completeness.

 


TOPTOP
Copyright © 1997-2008 Escher Technologies Limited. All rights reserved. Information in this document is subject to change without notice.