[ Applying Ccured with BLAST ]

Neither of these tools directly support the types of NULL checking that we are
looking for.  In fact, by design, these tools allow for simple arbitrary
application.  In our case, we are attempting to provide the tools with extra
insight into the design of the code to be checked, input for which the tools
were not designed.  Instead we will try and play off the relative strengths of
each of the tools in concert.

Ccured provides extensive, and possibly redundant runtime checking for
arbitrary C code.  These checks are inserted into the source just after the
preprocessing stage of the compile.  This being the case, direct application
would pollute the compiled output with excessive NULL checking causing a
significant decrease in performance.  We would much rather determine the
reachability of a given Ccured NULL check failing and extract all unreachable
states.

BLAST has the ability to check for state reachability with in a C source file
given the preprocessed output.  Therefore, it would be reasonable to have BLAST
check if the failure states of a Ccured processed source file are reachable.
However, the complexity of BLAST is exponential with respect to the number of
distinct states its tracking.  In this case, BLAST would need to check each
state which has a possible transition to the error state.  Further, each place
where a pointer is dereferenced within the source code would potentially be a
stated which BLAST would need to track.  Our approach will be to employ BLAST to
only check a single transition to the error state at a time.  This would have
the effect of reducing the overall complexity of the procedure.