The content of this document is proprietary.

A Comparison of MISRA C Testing Tools

Document Summary

Authors: SP & JJ

Date: 19 October 2001

Revision: 1.0

Presented at the MISRA C Forum 18 October 2001

Contents
1. Introduction................................................................................................................................ 2
2. The Tools.................................................................................................................................... 2
3. The Test Cases .......................................................................................................................... 2
3.1 Types.................................................................................................................................... 3
3.2 Linkage ................................................................................................................................. 3
3.3 Initialisation........................................................................................................................... 4
3.4 Operators ............................................................................................................................. 5
3.5 Conversions ......................................................................................................................... 5
3.6 Summary .............................................................................................................................. 6
4. An Industrial Example............................................................................................................... 6
4.1 Deviation Mechanism ........................................................................................................... 7
4.2 Industrial Scale Analysis ...................................................................................................... 7
4.3 Ease of Use.......................................................................................................................... 8
5. Discussion ................................................................................................................................. 8

1
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999

1. Introduction
This paper describes the work performed at
Pi Technology during the Summer of 2001 in
evaluating MISRA C static checking tools.
The purpose of this work was:
• to examine the consistency of
interpretation of MISRA C rules between
different checking tools;
• to determine whether MISRA C checking
tools are sufficiently mature for use on an
industrial sized software system.
The study followed two routes:
1. the production and application of a test
suite for individual MISRA C rules;
2. evaluating the testing tools behaviour
when presented with a production
software system.
The test suite contains examples of three
types of tests: those that clearly violate a
MISRA C rule, those that clearly do not
violate a MISRA C rule, and those for which a
rule violation is uncertain. The final test set
consists of around 600 test cases for 90 of
the 127 MISRA C rules.
The production software system used for
evaluating the tools was a Pi Technology
2. The Tools
Several MISRA C tool vendors made their
tools available for evaluation purposes. The
six tools evaluated included examples from
most of the major vendors.
• We evaluated both beta-test software
and long-standing mature software.
• We evaluated tools specifically targeted
at MISRA C checking and tools where
the MISRA C checking feature was a
small part of a larger static (and
sometimes dynamic) checking tool.
• We evaluated tools covering a significant
price range.
3. The Test Cases
The largest part of the tool study was based
around the production and application of a
set of test cases with which to exercise the
tools.
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
developed engine control system of around
100,000 lines of commented code.
The intent of this two-pronged attack is clear:
there is little value in a tool which can fully
verify that source code complies with
MISRA C but can only be used on tiny
systems. One of the significant features of
MISRA C is that it is intended for industrial
use, not simply for academic discussion.
Therefore we wished to verify not only that
MISRA C is sufficiently well defined to feel
confident in claiming compliance, but also
that the tools available for checking
compliance are adequate for use on systems
of industrial size and complexity.
The process of evaluating MISRA C tools is
important because the MISRA C guidelines
themselves require that tools are validated
(see MISRA C §5.2.3). Validation suites
exist for C compilers and it is reasonable to
ask tool vendors to provide proof that their
tool is conformant to the C standard. For
MISRA C checkers there is currently no
validation suite nor a validation process. The
onus of proving that a MISRA C checking tool
is adequate for purpose is on the software
developer.
Tools which provided MISRA C checking as
an add on feature (such as compilers that
implement limited MISRA C checking) were
not included in the study. Given the required
investment in installing a MISRA C
compliance process it seems unwise to base
this on a tool which is designed for use on
software for only one hardware platform.
The intention of this paper is not to identify
one particular tool as being "the best" nor to
identify straightforward bugs in the
implementation of particular tools. Our main
interest was in identifying where tools differ in
their interpretation of rules and where
possible to identify the causes of these
differences in interpretation.
This test suite was written without reference
to any previous tests and without reference to
a particular tool. It was intended to provide a
fair set of exercises.
2

In many cases we were able to decide when
developing tests what the expected result
was. Occasionally we were however unsure
whether the test case was compliant with a
specific MISRA C rule.
As the amount of time that could be spent on
this project was limited the test cases were
targeted at the most interesting rules. The
majority of the effort was expended on rules
that are:
• poorly defined (i.e., rules with several
possible interpretations), or
• difficult to implement.
This means that the results of the tests are
weighted towards showing the more negative
aspects of the tools and of MISRA C—rules
which are well specified and easy to
implement feature little.
The examples in this paper are obviously
intended to be short and concise. They are
extracted from the full test suite with names
shortened and irrelevancies (such as
unnecessary comments) removed. The
types S8, S16, S32, U8, U16, U32, F32 and
F64 are used for signed, unsigned, and
floating types of particular bit lengths; bool is
used to represent a boolean type
The following sections discuss particular
rules of interest.
3.1 Types
An important MISRA C rule that is intended
to promote portability of code and make the
code more explicit is rule 13: "The basic
types of char, int, short, long, float and
double should not be used, but specific-
length equivalents should be typedef’d for the
specific compiler, and these type names
used in the code." This rule is interesting
because it seems perfectly well specified and
it interacts with several other rules (which
we'll discuss later).
An obvious clue to identifying possible
interpretation differences here is that the rule
uses the standard C term "basic types"
(defined in ISO/IEC 9899:1990, §6.1.2.5) but
provides a different set of basic types to
those defined in the standard. The standard
C definition of a basic type is "the type char,
the signed and unsigned integer types, and
the floating types". Notice that the unsigned
integer types are specified here but not in the
rule text. This leads to the trivial test case:
unsigned f(void)
{ of the tool's understanding of standard C—a
return (0u);
}
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
This test case clearly violates the intent of the
rule yet does not violate the rule as written.
Of the six tools tested five claimed to check
this rule: three reported this as a violation of
rule 13, two did not.
If we consider the text of the rule again we
can ask "what does it mean to use a type?"
Clearly when we declare an object to have a
particular type we use the type but what
about declaring pointers to that type? This
leads to the following test case:
typedef unsigned char *str;
bool f(str s)
{
return (s[0] != '\0');
}
This test declares a pointer to a type that
"should not be used" and then uses a value
of that type (s[0] is of type unsigned
char) however none of the tools evaluated
produced a warning about the use of basic
types in such examples.
A further way in which we can use types is in
cast operations. Two of the tools failed to
report a violation of rule 13 for:
F64 fn(F64 f)
{
return (sqrt((double) f));
}
It could be simply stated that these problems
are implementation issues with the tools
under test; or that they are irrelevant example
cases unrelated to real world situations. But
the important issue is "is this code MISRA C
compliant?" The authors believe that each of
the examples in this section is in breach of
the intent of rule 13. If they were reviewing
this code for conformance with MISRA C
then they would reject it.
3.2 Linkage
An example of a rule that is reasonably well
specified but may cause implementation
problems is rule 24: "Identifiers shall not
simultaneously have both internal and
external linkage in the same translation unit".
This rule is well defined since it borrows
directly from the C standard §6.1.2.2: "If,
within a translation unit, the same identifier
appears with both internal and external
linkage, the behaviour is undefined." The
rule is however difficult to implement since,
as the rule 13 text states, "the rules for
linkage in C are complicated". This rule
therefore is a good candidate for testing each
solid standard C parser seems a prerequisite
for a good MISRA C checker.
3
 The content of this document is proprietary.

As acknowledged by the MISRA C Technical
Clarification document the example of a
breach of this rule in MISRA C is incorrect:
static S32 s;
void f(void)
{ for:
extern S32 s;
} {
At the point of the second declaration of s the
initial declaration is visible and therefore the
identifier inherits the static linkage from the
initial declaration. Two of the tools however
report rule 24 violations for this test case.
Two of the tools could not be convinced to
provide a rule 24 violation independent of the
input text.
In general the behaviour of the tools differed
significantly when processing this rule and
some tools have a clear misunderstanding of
the C linkage rules. Only one tool conformed
to our expectations for this class of tests.
3.3 Initialisation
Rule 30 states: "All automatic variables shall
have been assigned a value before being
used." This is a translation of a statement of
undefined behaviour from standard C §6.5.7:
"The value of an uninitialised object that has
automatic storage duration is used before a
value is assigned".
An obvious violation of this rule is:
S32 f(void)
{
S32 a;
return a;
} be used.
Rather alarmingly one tool which claimed to
check for this rule did not identify this as a
violation (although did identify the use of
uninitialised values in complex cases).
More complex examples expose differences
in the tools:
S32 f(void)
{
S32 a;
goto l;
{ return a;
S32 b = 0;
l: a = b;
} violation of rule 30 for this example based on
return a;
} tool also reported a violation but we were
In this example the returned value is derived
from an automatic variable whose
initialisation is elided by the jump statement
(see standard C §6.1.2.4). Only three of the
tools detected this error.
On a more positive note the control flow-
based analysis performed by some tools did
reduce the number of false warnings such as
S32 f(S32 a)
S32 b;
if (a == 1) {
b = 1;
}
if (a != 1) {
b = 0;
}
return b;
}
This (deeply unattractive) code has only two
executable paths - both of which lead to the
assignment of a value to b. Only two of the
tools seemed to identify that the branches
are related and avoided producing an
uninitialised variable warning. When the
second if statement was replaced with the
(preferable) else clause none of the tools
reported an error for rule 30.
These results (except for the first) can all be
stated to be "quality of implementation"
issues. However there is a more
fundamental issue. It seems clear that the
MISRA C rule is intended to be
straightforward rewrite of the standard C
undefined behaviour into more "engineer
friendly" language. However it is obvious that
the statements do differ: MISRA C says that
a variable may not be used, standard C says
that the value contained in the object may not
The tools seem to differ in their interpretation
of the word "used"; two of the tools seem to
believe that taking the address of a variable
constitutes use. For example:
S32 f(void)
{
S32 a;
S32 *p;
p = &a;
*p = 0;
}
Two of the tools incorrectly reported a
the use of the address-of operator. A further
unable to identify the root cause of its report.
This example might seem unlikely to cause
difficulties in realistic code but note that it

4
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999

prevents the initialisation of data by passing it
to functions such as memset.
Note that tools also need to be cautious
about marking data as initialised simply
because it has been passed by reference.
For example:
static void
init(U32 *p)
{
} A further complication comes from the use of
U32 f(void)
{
U32 a;
init(&a);
return a;
} {
This example is obviously missing some
initialisation code in init. Of the tools which
didn't report &a as a rule 32 violation none
identified that the variable was never
initialised.
The result here is clear: the implementation
of this rule is variable. Some of that
variability is due to simple quality of
implementation issues; some is probably due
to unclear wording in the MISRA C
document.
3.4 Operators
An example of an operator-related rule which
indicates significant tool variance is rule 42:
"The comma operator shall not be used,
except in the control expression of a for
loop." A for statement is defined in C as:
for (e1; e2; e3) stmt
Where e1, e2, and e3 are optional
expressions and stmt is a statement.
Unfortunately the term "control expression" is
not defined. The closest we can come to a
definition for this term is in a footnote in
standard C (footnote 76, §6.6.5.3) where it
calls the second expression in the for
statement the "controlling expression". Does
the MISRA C term mean the same as the
standard C term? If so then that is surely a
mistake, most examples of comma operators
in for loops occur in the first and third
expressions (the "initialisation" and "re-
initialisation" expressions).
None of the tools appear to implement the
rule if we assume that "control expression" is
the same as "controlling expression". The
tools behaved as follows:
1. One of the tools reports every comma
operator as a violation of this rule (even
comma operators within for statements);
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
2. one of the tools permits comma
operators in the initialisation and re-
initialisation expressions but not in the
controlling expression;
3. four of the tools allow comma operators
in any of the for loop expressions.
It is difficult to state which of these positions
is most valid.
the word "in". If there is a comma operator
within the expression then must this be at the
top level of the expression or can it be
embedded further within it? For example:
void f(void)
S32 a;
for (a = 0; a < 2;
g((a++, a)))
{
}
}
This contrived example demonstrates a
comma expression within a function call
within an expression within a for statement.
Is this acceptable? Three of the tools believe
that this is a violation of the rule, three do not.
Clearly the term "control expression" needs
to be defined if this rule is to have value.
Whether "in" is defined seems less important.
It is always possible to write code that
exploits this kind of loophole in the definition
of a rule. Such code is however likely to be
easily identifiable in a manual review, and
should be rejected.
3.5 Conversions
MISRA C rule 44 states: "Redundant explicit
casts should not be used." All but one of the
tools evaluated claim to check this rule. They
all reported a rule violation for:
S16 f(S16 a)
{
return (S16) a;
}
However if we look a little deeper there are
differences. One of the significant problems
involved with producing MISRA C compliant
code is in reconciling this rule with the rules
for "sized types" (rule 13), the rule for "integer
suffixes" (rule 18), the rule for "implicit
conversions" (rule 43) and the C promotion
rules.
As a reminder standard C §6.2.1.1 states
that: "A char, a short int, or an int bit-field, or
their signed or unsigned varieties, or an
enumeration type, may be used in an
expression wherever an int or unsigned int
5

may be used. If an int can represent all
values of the original type, the value is
converted to an int; otherwise, it is converted
to an unsigned int. These are called the
integral promotions.”
If we consider the following example:
S16 f(S16 a, S16 b)
{ return ((F64) a) / b;
return (S16) (a + b);
}
we cannot tell whether the cast is redundant
unless we know how S16 is implemented:
• on a 16-bit machine it is likely that S16
will be a typedef for int;
• on a 32-bit machine it is likely that S16
will be a typedef for short.
Four of the tools evaluated allow the user to
input the size of basic types. This allows the
checking tool to understand the effects of
promotion and balancing within expressions.
The tools did not provide a consistent set of
results for this test case. What was clear
was that at least one of the tools does not
understand C promotion rules (it claimed that
the expression "a + b" had type signed
short—the promotion rules force it to type
int), and one of the tools reported the cast as
being redundant independent of the basic
types of S16.
The MISRA C Technical Clarification
discusses this issue further and provides
some examples of non-compliant code:
F64 f(S32 a, S32 b)
{ Rule 42 is again a good example.
return ((F64) a) /
((F64) b);
} unexpected behaviours, or where static
This is marked as non-compliant since
balancing is sufficient to force the conversion
4. An Industrial Example
The test suite discussed above provides
some detailed information on how the various
tools implement MISRA C rules. It is
however important to consider not only how
well the tools implement the specific rules but
how easy the tool is to use; and more
specifically how easy the tool is to use in an
industrial setting.
There are several considerations that affect
the usability of the tool:
• how does the tool handle deviations from
MISRA C;
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
of the second operand. However none of the
tools evaluated identified a rule 44 violation
for this text.
The recommended way of writing this would
be (again from the technical clarification):
F64 f(S32 a, S32 b)
{
}
This however produces a rule 43 violation
from one tool and a rule 48 violation from
another.
It is clear that this rule is insufficiently well
defined to be able to claim compliance.
3.6 Summary
Executing the test cases demonstrated that
there were significant differences in the
interpretations of the rules between the
various tools. The rules which demonstrated
the largest variance were:
• The rules related to types. The required
behaviour of MISRA C checking tools is
difficult to understand when the various
rules on types, integer suffixes and
casting are combined.
• Rules which used obvious but undefined
terms, e.g., "redundant explicit casts" (in
rule 44), "control expression" (in rule 42),
"unreachable code" (in rule 52), or
"effectively boolean" (in rule 49).
• Rules where the vendors had to make a
choice between implementing what the
rule said and what the rule meant.
In total we identified around 30 rules with
checking tools had significantly differing
implementations of the rule.
• how well does the tool scale to industrial
sized input;
• how well can the tool be integrated into a
software development process;
• how appealing is the tool to software
engineers.
The usability of the tools was tested by
attempting to analyse a reasonably sized
program: a 100,000 line production quality
engine controller.
6

This software was written to an appropriate
coding standard and has been previously
analysed for errors using static analysis tools
and by manual review. The software was not
written to be MISRA C compliant (the project
predates the publication of MISRA C)
however the coding standard used has some
overlap with MISRA C (e.g., the software is
developed with "sized types" compliant with
rule 13). We expected that MISRA C tools
would identify many MISRA C violations but
few actual errors in the code.
4.1 Deviation Mechanism
The MISRA C guidelines place a strong
emphasis on operating a deviation
procedure: a product need not be free from
violations of MISRA C rules so long as the
violations are documented and signed off by
a "C language expert together with manager
level concurrence." For a large project the
number of deviations and the scope of those
deviations will require significant
management and maintenance. An inability
to support this process reduces the value and
usability of a tool.
There are two obvious mechanisms for
documenting deviations:
1. Insert the deviation statement into the
source code at an appropriate point. The
review and sign off of this source code is
the deviation procedure.
2. Record the list of deviations produced by
a tool and sign off this document. The
deviation process then becomes the sign
off of a list of errors.
The choice between these two processes is a
management and process issue. It is worth
noting however that inserting the deviations
into the source code allows for easier
software maintenance: old violations are not
highlighted by the checker. Only the
additional rule violations are shown. The
alternative is to be presented with a new set
of deviations to compare against the old.
Of the six tools we evaluated:
• one had no provision for deviating for
specific rules (it was however possible to
select only required rules);
• one had provision for selecting the
required rules on a per-analysis basis;
• four had provision for inserting deviation
documentation within the source code.
The mechanisms for inserting deviations into
the source code were either through
#pragma directives or through stylised
comments. Note that the insertion of a
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
pragma in the source code requires further
documentation (in order to satisfy rule 99)
and introduces further implementation-
defined behaviour (the point of a pragma is to
introduce implementation-defined behaviour).
Given that the deviation will need further
documentation than a pragma directive alone
the choice of stylised comments seems
preferable.
One small but practical point is the manner in
which deviations are handled for tools which
map MISRA C rules to legacy C rules (for
example a static tool may implement several
internal rules which together implement a
MISRA C rule; this is rarely a one-to-one
mapping). Some of these tools enable the
user to deviate from a specified internal rule
but not a specified MISRA C rule.
The effect of this is that it is necessary to
understand the tool's mapping between
internal rules and MISRA C rules in order to
define deviations. Since the mapping is not
necessarily one-to-one a single internal rule
deviation may implement deviations from
several MISRA C rules, or several internal
rule deviations may be necessary to deviate
from a single MISRA C rule. In general the
management of this process is likely to be
cumbersome. The ability to deviate from
specific MISRA C rules simplifies this
process.
4.2 Industrial Scale Analysis
If a tool is going to be useful in industry then
it needs to be able to handle industrial size
programs. Our input does not seem an
extreme example. The source code consists
of 115000 lines of commented source code
in:
• 34 source files (84000 lines in total);
• 34 header files (31000 lines in total).
One of the tools evaluated performed single
translation unit checks only. It was not
practical to analyse the entirety of the
system. Of the remaining five tools one took
around 4 hours to analyse the source code
(although more often than not the tool failed
part way through the analysis). The
remaining tools took between 25 minutes and
15 seconds to perform the analysis.
Of course the value of the tool is dependent
on both its speed and usability and on the
quality of its results - we do not wish to
penalise tools which do more thorough (or
deeper) analysis. It is clear however that a
tool which takes four hours to analyse a
program of this size is probably not going to
be often used, and a tool which takes 15
7

seconds could be usefully incorporated into
the normal software build process.
The most disappointing result from the
industrial case study was the large number of
false positive results identified. As previously
stated the software had been developed to a
reasonably strict coding standard. We did
expect that tools would identify a number of
MISRA C rule violations but one tool
managed to produce approximately 40000
violation reports. The vast majority of these
were false positives (due to an insufficient
analysis of the source code or to
misunderstandings of the C language). It
was difficult to identify any real errors in the
software when the "noise" level was so great.
Applying these tools to existing source code -
even source code developed to a similar
coding standard - with the intention of gaining
MISRA C compliance, is likely to be a long
term activity.
4.3 Ease of Use
The incorporation of static checking tools into
the build process seems to be a valuable way
of getting engineer buy-in to the MISRA C
process. Most software engineers are
somewhat sceptical about static checking
and coding standards; automating the
checking process at the build level enables
instant feedback of errors saving debugging
time. Several of the tools are intended for
graphical use only. This makes the
automation of running the tool awkward and
will probably result in the tool being used only
at the code review stage of development. In
the typical automotive development
environment it is likely that the software will
have been executed on the target by this
5. Discussion
The MISRA C guidelines provide some
guidance on the selection of static checking
tools. In MISRA C §5.2.3 it is suggested that
the static checking tool is validated by the
production of test cases to exercise the tool
and by exercising the tool with known good
code.
We have followed this model in evaluating
the tools. The basic observations from this
are:
1. Producing a test suite capable of
demonstrating that a tool satisfactorily
identifies MISRA C violations is a
significant piece of work.
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
stage, and much of the benefit of static
analysis has already been lost.
The benefit of being able to analyse an entire
project cannot be over-emphasised. Tools
which enable the analysis of a single
translation unit are valuable; but a change to
a single header file can trigger a huge
amount of work as all files that include this
have to be reanalysed. This re-examination
is necessary but tools which can analyse
multiple files make it much simpler. The
single translation unit tools are also limited in
the number of rules they can check: rules
such as rule 25 "An identifier with external
linkage shall have exactly one external
definition." can only be checked by examining
the entire program. Note however that even
tools which analyse the entire project will
have some issues of this nature when
presented with a project developed in a
mixture of both C and other languages (e.g.,
the typical embedded system mix of C and
assembler).
MISRA C and MISRA C checking tools are
only successful if they are used on real
projects. This means that engineers need to
accept the standard and accept the checking
tools. There are some obvious lessons from
our short study:
• the tools need to be reliable and capable
of analysing the systems that are being
produced;
• the tools need to handle deviations
intelligently;
• the tools need to run sufficiently quickly
and be sufficiently easy to automate for
the users to bother using them;
• the tools need to produce very few false
warnings - we saw far too many.
2. In producing a test suite it is imperative
that there is an expected result.
3. Passing a large body of code through a
MISRA C checker will reveal much about
the tool's robustness and usability, but
little about its checking qualities.
Our test suite, which is incomplete and
largely undocumented - it is certainly not of
validation quality - took some 8 man weeks to
produce. It seems unreasonable to expect
software developers to go through this
process in order to evaluate a checking tool
for a published language standard; yet if they
do not then they cannot reasonably claim to
be producing MISRA C conformant code.
8

The tool evaluation process will also need to
be repeated whenever it is necessary to use
a different checking tool (e.g., if a new
version is shipped by the tool vendor or if a
customer demands that a specific tool is
used on a project).
When developing the test suite there where
many tests where we could not determine by
examining the MISRA C guidelines whether
the code violated the rule. Of course
specifications of any sort usually have some
ambiguity but there were areas where
detailed examination of the MISRA C rule
and, where possible, the source of the rule
provided no real confidence in what the rule
meant.
A good example of this is rule 108: "In the
specification of a structure or union type, all
members of the structure or union shall be
fully specified." No-one could object to this
rule, but unfortunately its meaning is not clear
when considered more carefully: what does
"fully specified" mean? The C standard
requires that a structure definition shall not
contain an incomplete type (§6.5.2.1) and the
cited source reference ("undefined 35") does
not seem relevant.
Until issues such as these are clarified it is
difficult to see how a formal statement of
MISRA C compliance can be made. It is
impossible to claim compliance with a rule
that cannot be understood. It is possible that
over time checking tools may tend towards a
uniform interpretation of the rules. Even if
this does occur there are still rules that
require manual inspection (such as rule 4).
Ambiguity in these rules is even more difficult
to manage: instead of several tools having
their own interpretation of the rule we have
each individual engineer having a different
interpretation.
Each of the MISRA C checking tools we
examined performed valuable checks and
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, UK
Tel: +44 (0) 1223 441434 Fax: +44 (0) 1223 203999
The content of this document is proprietary.
would be a useful tool for the software
developer. There were however significant
differences in the quality of checking
performed by the tools:
• the number of rules tested differed
between the tools;
• the interpretation of many of the rules
was not consistent - several of the
interpretations were baffling, it was
difficult to see the relationship between
the MISRA C rule text and the
implemented rule;
• the tools differed in the extent to which
they implemented the MISRA C technical
clarification - some of the tool vendors
were unaware that this document
existed;
• the usability of the tools differed
significantly, in particular there are three
orders of magnitude difference in speed
between the fastest and the slowest
tools;
• some tools had clearly had insufficient
testing on industrial sized systems -
these were not necessarily the tools
made available in beta release.
The conclusion must be that claims of
MISRA C compliance need to be based on
significant effort in validating the checking
tool. The tools we evaluated showed
significant differences that the user of the tool
needs to understand before claiming
compliance.
We would like to thank the tool vendors for
their co-operation in this work. The support
we received from all the vendors during our
evaluation was faultless. However we cannot
enter into correspondence with vendors,
users or potential customers for these tools
9