\chapter{Background}
\label{chap:overview}

This chapter provides background information on how \satabs operates. The
reader who is only interested in running \satabs may skip to the next
chapter.

Even for very trivial C programs it is impossible to exhaustively examine
their state space (which is potentially unbounded). However,
not all details in a C program necessarily contribute to a bug, so in
theory it is sufficient to examine the parts of the program that are
somehow related to a bug. In practice, many static verification tools
(such as \texttt{lint}) try to achieve this goal by applying 
heuristics. This approach comes at a cost: bugs might be overlooked
because the heuristics do not cover all relevant aspects of the program.
Therefore, the conclusion that a program is correct whenever such a static
verification tool is unable to find an error is invalid.

\section{Abstraction and Refinement}

\input{cedar}

A more sophisticated approach that has been very successful recently
is to generate a \emph{sound} abstraction of the original program (see
Figure~\ref{fig:cegar}).
In this context, \emph{soundness} refers to the fact that the abstract program
contains (at least) all relevant behaviours (i.e., bugs) that are present
in the original program. In Figure~\ref{fig:cegar}, the component 
labelled $\alpha$ is responsible for stripping details from the
original program. The number of possible behaviours
increases as the number of details in the abstract program decreases.
Intuitively, the reason is that whenever the model checking tool lacks the
information that is necessary to make an accurate decision on whether a 
branch of an control flow statement can be taken or not, both branches
have to be considered. In the abstract program, a set of concrete 
states is subsumed by means of a single abstract state. Consider
Figure~\ref{fig:states}: The concrete states $x_1$ and $x_2$ are
mapped to an abstract state $X$, and similarly $Y$ subsumes $y_1$ and $y_2$.
However, all transitions that are possible in the concrete program are
also possible in the abstract model. The abstract transition $X\rightarrow Y$ 
summarizes the concrete transitions $x_1\rightarrow y_1$ and 
$x_1\rightarrow y_2$, and $Y\rightarrow X$ corresponds to 
$y_2\rightarrow x_2$. The behaviour $X\rightarrow Y\rightarrow X$
is feasible in the original program, because it maps to 
$x_1\rightarrow y_2\rightarrow x_2$. However, 
$Y\rightarrow X\rightarrow Y$ is feasible only in the abstract model.

\input{states}

The consequence is that the model checker 
(labeled as $\pi$ in Figure~\ref{fig:cegar}) possibly reports a
\emph{spurious} counterexample. We call a counterexample spurious
whenever it is feasible in the current abstract model but not in the
original program. However, whenever the model checker $\pi$ is unable
to find an execution trace that violates the given property \texttt{p}
we can conclude that there is no such trace in the original program, either.

The feasibility of counterexamples is checked by symbolic simulation
(performed by component $\delta$ in Figure~\ref{fig:cegar}). 
If the counterexample
is indeed feasible, \satabs found a bug in the original program and
reports it to the user.

Infeasible counterxamples 
(that originate from abstract behaviours that result from the omission of
details and are not present in the original program) are never reported
to the user. Instead, the information is used in order to refine the
abstraction such that the spurious counterexample is not part of the
refined model anymore.
For instance, the reason for the infeasibility of 
$Y\rightarrow X\rightarrow Y$ in Figure~\ref{fig:states} is that 
neither $y_1$ nor $y_2$ can be reached from $x_2$.
Therefore, the abstraction can be refined by partitioning $X$.

\input{refinement}

The refinement steps are illustrated in Figure~\ref{fig:refinement}.
The first step $(1)$ is to generate a very coarse abstraction with
a very small state space. This abstraction is then successively
refined ($2, 3,$\ldots) until either a feasible counterexample is found or the 
abstract program is detailed enough to show that there is no
path that leads to a violation of the given property. The problem
is that this point is not necessarily reached for every input program,
i.e., it is possible that the the abstraction refinement loop never
terminates. Therefore, \satabs allows to specify an upper
bound for the number of iterations. \attention Note that whenever
this upper bound is reached and no counterexample was found, that
does not necessarily mean that there is none. In this case, 
you cannot make any conclusions at all with respect to the correctness 
of the input program.

\section{Properties}\label{sec:properties}

We have mentioned \emph{properties} several times so far, but we
never explained \emph{what} kind of properties \satabs can verify.
We cover this topic in more detail in this section. 
While users of \satabs
almost never have to be concerned about the underlying refinement
abstraction algorithms, understanding the classes of properties that 
can be verified is crucial.

\satabs allows the verification of following properties:

\begin{itemize}
  \item \textbf{Buffer overflows.} For each array, \satabs checks whether 
    the upper and lower bounds are violated whenever the array is accessed
    (i.e., whenever the program reads from or writes to the buffer).
  \item \textbf{Pointer safety.} \satabs searches for  
    \texttt{null}-pointer dereferences.
  \item \textbf{Divison by zero.} \satabs checks whether there is
    a path in the program that executes a divison by zero.
  \item \textbf{User specified assertions.} This is the most generic
    class of supported properties. \satabs checks for assertion violations.
    The user can use the \texttt{assert} function to specify 
    arbitrary conditions that have to hold at certain points in the
    program.
\end{itemize}

(A more detailed list of properties checked by \satabs can be found
in Section~\ref{sec:features}.)
All the properties described above are \emph{reachability} properties.
They are always of the form ``Is there a path such that property \ldots\ 
is violated?''. The counterexamples to such properties are always
paths. Users of the Eclipse plugin for \satabs can step through 
counterexamples in a way that is similar to debugging programs.
The installation of this plugin is explained in 
Section~\ref{chap:installation}.

In general, properties are specified by \emph{predicates}. Examples
for such predicates are
\begin{itemize}
\item $(i>=0)$ and $!(i>=\texttt{MAX-1})$. Such predicates are
  automatically introduced by \satabs whenever an array \texttt{a}
  of size \texttt{MAX} is accessed with index \texttt{i} (i.e., 
  whenever \texttt{a[i]} occurs in the program). They make sure that
  the lower and upper array bounds are not violated.
\item $!(m \% 2 == 0)$. This predicate is introduced if the user
  has stated by means of an assertion that \texttt{m} has to be odd
  (i.e., if \texttt{assert (m \% 2);} occurs in the program).
\end{itemize}

\satabs calls these predicates \emph{claims}. Each claim 
is associated to a specific line of code, i.e., a claim is violated when the
predicate can become false at the corresponding program location. Claims are
(implicitely) stated within the program: Currently there is no possibility
to introduce claims other than by adding assertions to the program. The
claims for a program can be inspected by using the \texttt{--show-claims}
option of \satabs. \satabs is able to check several claims at once.
However, as soon as a violation of one claim is found, it is reported.  A
single claim can be verifie by using the \texttt{--claim <n>} option of
\satabs, where \texttt{<n>} denotes the index of the claim in the list
obtained by calling \satabs with the \texttt{--show-claims} flag. Whenever
a claim is violated, \satabs reports a feasible path that leads to a state
in which the predicate that corresponds to the violated claim evaluates to
false.

\label{lbl:library_functions}
\attention\satabs cannot check programs that use functions that are
only available in binary (compiled) form\footnote{This restriction
is not imposed by the verification algorithms that are used by \satabs --
they also work on assembly code. The reason is simply that so far
no assembly language frontend is available for \satabs.}. At the moment,
(libarary) functions for which no C source code is available have to be
replaced by stubs. The usage of stubs and harnesses (as known from unit 
testing) also allows to check more complicated properties (like, for 
example, if function \texttt{fopen} is always called before \texttt{fclose}).
This technique is explained in detail in Chapter~\ref{chap:verifying}.







