Differences between static analysis and model checking - IAR Systems

y Anders Holmberg, IAR Systems
Are static analysis and model checking at odds?
A viewpoint on two methods of software verification
This article will look briefly at some of the differences between static analysis tools in general and
domain specific model checking. For the purpose of this discussion a static analysis tool is a tool that
analyzes source code to detect potential run-time problems with the code. For domain specific model
checking we will use the verification engine built into the IAR visualSTATE state machine design tool as
an example.
An exhaustive discussion on static analysis tools for source code analysis will naturally not fit into this
article; the field is subject to lots of research and a lot of groundbreaking results have been achieved in
the last few years. However, if you look closely you run into a classification problem because there a
many different technologies with varying strengths and weaknesses used and sometimes combined into
the same tool set... At one end of the spectrum you find pattern based checkers like MISRA checkers,
source code metrics tools and some well-known tools that can do a fair amount of useful checking on
the fuzzy line between syntax and language semantics.
On the other end you have tools that use techniques called “symbolic execution” and “abstract
interpretation” and even “model checking” to draw very advanced, and surprisingly accurate conclusions
about the safety and integrity of your code base.
In essence most advanced commercial static analysis tools will analyze your source code and try to
draw conclusions about several security and integrity properties of your code. Typical checks include:
• Null pointer dereference and use after free
• Division by zero
• Buffer overruns
• Variable use before initialization
• Memory leaks
• Dead code, i.e. code that will never be executed
• Etc…
Some of these tools let the user write checks for either simple pattern based properties, or in the more
advanced tools, checks for temporal properties as well as assertive checks. A temporal property might
be “Function A() must always be called before function B(), even if other functions are called in
between.”
To complicate the picture, some tool sets on the market combine static analysis with the generation of
test cases and test harnesses for automatic testing. The testing phase can then complement the static
analysis by testing for example memory properties in runtime as well as testing the functional aspects of
the application.

Testing, testing…
With recent advances in the capabilities of static analysis tools it can be argued that any software
development shop that take the issue of software integrity and safety seriously should have at least one
such tool available and use it regularly. However, even advanced static analysis techniques will not find
all issues with your code. For example, even if a tool finds many true crash bugs in your program that
you would have been hard pressed to find with traditional testing it will not help you decide if you have
actually implemented the right functionality. In a way you can say that static analysis can help you
determine whether you have built your thing the right way, but not if you have built the right thing…
Another built-in problem for static analysis tools is that they are dependent on the language semantics,
which will have the effect that some checks are either very difficult to create or impossible, even if you
know what the code is trying to achieve. All commercial analysis tools also have a problem with “false
positives”, i.e. reported errors that are in fact no problems, which is a symptom of necessary
simplifications in the analysis phase. That is by no means an indication that you should avoid these
tools, but rather that to be able to give any results at all in a reasonable amount of time the tools have to
make certain assumptions.
The state of affairs
We will now take a look at an example where static analysis cannot really help you. Consider the
following state machine design. It is of course a made up example and created solely for this article, but
it serves well to illustrate the underlying problem.
Figure 1: State machine
If you look closely at the design you will notice that there might be a problem with the transition from
state Strange to state C. The transition is only enabled if the variable ‘x’ is below 10, so if current state is
Strange and x does not fulfill the condition the machine gets stuck. This might be intentional, but
probably not. This kind of situation is called a dead-end. In the example it is quite easy to spot this just
by a quick glance at the model, but it is no means trivial or even possible if the machine is very complex;
especially if hierarchy and parallelism is involved. (For this example we ignore the question of where ‘x’
is updated and how.)
If we have a specialized model checker that knows about state machine semantics it is possible to spot
problems like this automatically, even for very complex designs. The reason is that the model checker in
this case cares only for the properties of the state machine taken as an abstraction, blissfully ignoring
how the state machine might be implemented in code. Or to put it another way: we are mapping a well
defined state machine semantics onto the much more expressive C language—if we assume for a
moment that the translation from the design into code is correct it is also a reasonable assumption that
Page 2

we can check the design at the design level instead of the code level. By checking the design at the
model level we also have the advantage of knowing what we are checking and can thus invent
specialized checks. As we noted above, it is close to impossible for a general static analysis tool to
figure out the exact high-level intent of any piece of code we feed to it. What’s more, even if the static
analyzer is powerful enough to figure out that it is a state machine it is analyzing, there are checks that
are very difficult to perform in the source code context. We will now take a look at such an example
based on the state machine in Figure 1.
The code to success
Take a look at the following code:
Figure 2: State machine code
The code represents a part of the state machine design translated to straight C code. The pattern is
pretty obvious; each event has its own case label in the switch statement and for each event we check
what state is currently active by checking the value of the variable ‘CS’ (Current State) against each
state name that has an outgoing transition triggering on the event. If we find a match the corresponding
action is performed, which for most of the transitions in this model is just to set the working state to the
new state. Did you notice how we also checked the condition ‘x

When that transition fires we call the action function before setting the new state. When we are done
processing an event, we set the current state to the working state. (It might seem unnecessary to
separate current state and working state, but that way we can get the benefit of checking in runtime for
conflicting transitions. The code for that is not shown here.)
This code is very close to what you would get by code generating the design in visualSTATE, but I’ve
granted myself some artistic freedom in removing details that are only relevant in real production code.
The verification engine in visualSTATE can among other things find the following properties in a state
machine:
• Transitions that are in conflict. I.e. two or more transitions out of a state that can be activated
by the same event and does not have mutually exclusive guard conditions.
• Reachability: Can we reach a certain state, and can we activate a certain transition?
• Dead-ends. A dead-end is a state that you can enter but never exit. However, a state can be
either a dead-end already from the start or become one during the execution life span, i.e. a
state that has been possible to enter and exit multiple times during execution might all of a
sudden become a dead-end because some guard condition on an outgoing transition is now
impossible to fulfill. The possible dead-end in state Strange is of the latter type.
Can a general static analysis tool handle these situations? No, and yes—read on…
If we start with the question of reachability, what does it mean in the context of the generated C code?
Let’s take transition reachability first, because that concept is fairly simple: Look at line 58-61. These
lines implement the logic for the transition from state A to state C. It is not difficult to realize that if we
reach the statement at line 60 that assigns the new state to the working state variable, we have indeed
activated that transition. So from a static analysis point of view it should be enough to check that there is
no dead code in the code that implements the state machine.
However, it’s not obvious that a particular tool will be able to deduce with 100% certainty that a transition
is really reachable due to imprecision in the analysis. But for the transitions it is at least easy to map the
concept of reachability from the design to the code.
What happens if we instead look at reachability of states? Now it gets interesting! What does it even
mean in the code context for a state to be reachable? It means that the current state variable or the
working state variables should at some point be equal to the state that we are interested in. This is a
property that a general analysis tool will have no idea about. But it is, at least in theory, possible to reuse
the argument for transition reachability—we can argue that if one or more transitions are not
reachable or possible to activate, their destination states are unreachable if all transitions going to these
states are unreachable. This might be feasible for small state machines, but will soon get out of hand as
complexity grows because every warning about unreachable code would have to be cross-referenced to
the design.
A simpler but still rather messy way of checking state reachability is to extend the program with explicit
checks for each state name before setting the current state to the value of the working state. Here is an
example of how to do it:
if (WS != STATE_UNDEFINED)
{
if (WS == State_B)
{ ; /* Can we reach state B? */ }
if (WS == State_C)
{ ; /* Can we reach state C? */ }
if (WS == State_A)
{ ; /* Can we reach state A? */ }
CS = WS;
}
Page 4

Note that the purpose of each test is just to make sure that we can reach a particular state, we do not
want to change the semantics of the program. That is why we have an empty statement in each ifclause.
The empty statement is just there to be reachable if the corresponding state is reachable.
Depending on the tool and the power of the analysis engine this might or might not work. So state
reachibility can also be seen as a kind of code liveness, which can be messy to map to the generated
code. Note that in some static analysis tools you do not need to modify the program with the tests, but
can instead express them in a dedicated checker. But the point is that you will have to explicitly name
each interesting state in an assert-like way. And this will have to be extended and modified in lock-step
with the state machine design.
So, we’ve seen so far that questions of basic reachability are in theory possible to answer with the help
of a static analysis tool. (I.e. the question “can we reach this state, or that transition?” can be mapped to
“can we ever reach this particular statement?”) It is however an open question whether a particular tool
in reality can figure out what’s going on for a complex design, due to analysis precision and available
computing power etc. It can also involve a lot of tedious semi-manual work to annotate the code or
create specialized checkers.
Running into a dead-end
Let us now look at a question that is far trickier to answer. We have already talked a bit about dead
ends, i.e. states that can be entered but never exited because no guard condition on transitions leading
out of the state can be fulfilled.
Being a dead-end state can very well be a temporal property, so the fact that we have exited it a
thousand times does not guarantee that the state is not a dead-end. It can be further complicated by the
fact that a state might look like it has become a dead-end, because it is dependent on some property of
a parallel region in the state machine that is not true at the moment, but might become true at a later
time.
How do we map the concept of a dead-end to a property of the implementation code? We cannot use
the basic checks for reachability, as those only concern themselves with statements being reachable at
least once. What does it mean in the C code if we enter a dead-end? It in essence means that if the
code is processing a particular event, that event will just be ignored. Or rather, we will execute some
tests like the following code, to determine if any transitions can fire. And it is perfectly normal that such a
test does not evaluate to true—the fact that we are not taking any action based on a particular event
does not generally mean that the state machine has entered a dead-end, because there might be other
transitions out of a state triggering on different events. This means that we might have several, even a
very large number, of invocations of the state machine code were nothing will happen—at least not for
the transitions we are interested in...
if ((CS == State_Strange)
&& (x < 10))
{
WS = State_C;
}
If we want to try to capture the dead-end property in C semantics we will have to do something like the
following (in pseudo code):
if ((event = e && CS == State_under_test) && !guard1 && !guard2 && … && !guardn)
{
/* State_under_test *might* be a dead end, but only if all guards are eternally
false */
}
We have to check for each state for all outgoing transitions triggering on a specific event whether their
guards are all false. This situation might indicate a dead-end. But only if we can prove that all the guard
Page 5

expressions can never be true after some point in time. This must be repeated for all events that can
trigger a transition out of a state. And so far we have only checked one state…
So given ordinary C code it is difficult to express the dead-end property in any meaningful way; in fact, is
does not really get any simpler by realizing that the code is a pure state machine. And this is mainly
because there is a gap between the semantics of the state machine abstraction and the implementation
language.
This gap is not unique for the state machine abstraction, so given that you work in a problem domain
where some form of formal verification or model checking is available you might reap huge benefits by
using it – together with a competent static analysis tool, of course!
Page 6