For instance in the program below, instead of considering all the possible input arrays - there are (almost) infinitely many -  cccheck only considers an abstraction of them.

public int Max(int[] arr)
{
 Contract.Requires(arr != null);
 Contract.Requires(arr.Length > 0);

 var max = arr[0];
 for(var i = 1; i < arr.Length; i++)
 {
 if (max < arr[i]) max = arr[i];
 }

 return max;
}

Now the question is which abstraction of the array we should keep?

A very simple abstraction is whether the input array is null or not. This help us to prove the absence of null pointer exceptions – i.e., in the example, all the array loads are safe.

A more refined abstraction keeps track of the array indexes. In our example, the local variable i is initialized to 1 and always incremented. Therefore we can infer that it always assume values in the interval [1, Int32.MaxValue]. Furthermore, inside the body of the loop we also know that i < arr.Length. As a consequence, we can deduce that is safe to index the array with i, i.e., no out-of-bounds exception is ever thrown, no matter which is the concrete array.

A false myth is that abstract interpretation is good only for those “simple” properties, and for “real” verification we need some other technique, as for instance deductive verification. For instance, in the example below the myth goes as abstract interpretation is unable to infer that Max is effectively computing the max of the array. Let’s debunk the myth.  We can ask cccheck to tell us which postcondition infers for our program (we use the extra option “-suggest methodensures”):

…: message : CodeContracts: Suggested ensures: Contract.Ensures(Contract.ForAll(0, arr.Length, __k__ => arr[__k__] <= Contract.Result<int>()));

…: message : CodeContracts: Suggested ensures: Contract.Ensures(Contract.Exists(0, arr.Length, __j__ => arr[__j__] == Contract.Result<int>())); 

The analyzer infers that the returned value is larger or equal to all the elements in the array and that there exists one element in the array that is equal to the returned value, i.e, and the returned value is effectively the maximum element and not a simple upper bound!

To sum up, let me illustrate why we use abstract interpretation and not, e.g., deductive verification in CodeContracts. Using deductive verification, i.e., Hoare-Logic style reasoning, one should provide all the boundary contracts and the loop invariants. Our Max will then look like as this one:

public int Max(int[] arr){

 Contract.Requires(arr != null);
 Contract.Requires(arr.Length > 0);
 Contract.Ensures(Contract.ForAll(arr, el => el <= Contract.Result<int>()));
 Contract.Ensures(Contract.Exists(arr, el => el == Contract.Result<int>()));

 var max = arr[0];
 for(var i = 1; i < arr.Length; i++)
 { // Those below are effectively Loop invariants, CC has no Contract.Invariant(...)
 Contract.Assert(i >= 1); 
 Contract.Assert(Contract.ForAll(0, i, __j__ => arr[__j__] <= max)); 
 Contract.Assert(Contract.Exists(0, i, __j__ => arr[__j__] == max));

 if (max < arr[i]) max = arr[i];
 }

 return max;
}

Compare it with cccheck, which infers, precondition, postcondition, and loop invariants!

public int Max(int[] arr)
{ // Precondition & postcondition inferred   
 

 var max = arr[0];
 for(var i = 1; i < arr.Length; i++)
 { // Loop invariant inferred
 if (max < arr[i]) max = arr[i];
 }

 return max;
}

…: message : CodeContracts: Suggested requires: Contract.Requires(arr != null);

…: message : CodeContracts: Suggested requires: Contract.Requires(0 < arr.Length);

…: message : CodeContracts: Suggested ensures: Contract.Ensures(Contract.ForAll(0, arr.Length, __k__ => arr[__k__] <= Contract.Result<System.Int32>()));

…: message : CodeContracts: Suggested ensures: Contract.Ensures(Contract.Exists(0, arr.Length, __j__ => arr[__j__] == Contract.Result<System.Int32>()));

But how it works?

Let me illustrate the inference of preconditions with this example

private int Max(int[] a)
{
  var max = a[0];
  for (var i = 1; i < a.Length; i++)
  {
    var tmp = a[i];
    if (tmp > max) max = tmp;
   }
  return max;
  }
}

private void CreateTheArrayAndDoSomething(int size)
{
  var array = new int[size]; 
  // ... fill the array ...

  var arrayMax = Max(array);

  // ... do something else ...
}

public void PublicAPI(int size)
{
  Contract.Requires(size != Int32.MinValue);

  if (size < 0) size = -size;

  CreateTheArrayAndDoSomething(size);
}

The static checker first analyzes the method Max. It determines that if the input array is null or it is empty, then an error will definitely happen. If we enable the suggestion of requires, it will report (remember to enable "Suggest Requires" to see those messages)

... : CodeContracts: Suggested requires: Contract.Requires(a != null);

... : CodeContracts: Suggested requires: Contract.Requires(0 < a.Length);

Those preconditions are necessary for Max to be correct: If they are violated Max will cause a runtime exception to occur. The static checker is also smart enough to determine that those preconditions are sufficient for Max to be correct: If satisfied, then the Max will never throw a runtime exception. As a consequence the static checker will not report any warning for Max, but it pushes the condition to the caller.

The caller passes a freshly allocated array of length size to Max. As a consequence, the first condition (a != null) is satisfied, but not the second one, which is further propagated to the caller:

... : CodeContracts: Suggested requires: Contract.Requires(0 < size);

The caller, PublicAPI, is careful enough to check whether the input values is negative in which case it negates it. Furthermore, it requires the input to be different from the MinValue which will cause an overflow on negation. Nevertheless, it forgot the case when size == 0, which will cause an error downstream. The static analyzer cannot push the condition further up in the call chain, as it reached the public surface. As a consequence it emits a warning as well as the inter-procedural trace that will cause the error

... : CodeContracts: Missing precondition in an externally visible method. Consider adding Contract.Requires(0 != size); for parameter validation. Otherwise the following sequence of method calls may cause an error. Sequence: PublicAPI -> CreateTheArrayAndDoSomething -> Max

The precondition inferred by cccheck is by design a condition to the error: if some caller fails to satisfy it, then a runtime error will occur. This makes the cccheck analyzer different from other tools, as all the inferred preconditions are sound.

First, we define a function that tell us if we can move from one state in the (extremely important) process of cooking pasta, to the next one (for theory lovers, we are defining the transition relation of a finite state machine).

enum CookPasta { BoilWater, AddSalt, AddPasta, Stir, Strain, Eat }

[Pure]
static public bool CanTransition(CookPasta from, CookPasta to)
{
 switch (from)
 {
  case CookPasta.BoilWater:
  return to == CookPasta.AddPasta || to == CookPasta.AddSalt;

  case CookPasta.AddPasta:
  return to == CookPasta.AddSalt || to == CookPasta.Stir;

  case CookPasta.AddSalt:
  return to == CookPasta.AddPasta;

  case CookPasta.Stir:
  return to == CookPasta.Strain;

  case CookPasta.Strain:
  return to == CookPasta.Eat;

  case CookPasta.Eat:
  return false;

  default:
   throw CodeContractsHelpers.ThrowIfReached("missing case");
 }
}

Now we'd love to prove some properties about our state machine. For instance that the first thing to do is to boil water or that once we eat all our pasta we are done. We can do it by defining two methods as below (again for the theory-loving people those acts as lemmas to be proven by the static analyzer).

Important. To repro the examples below, make sure that you have the "Infer ensures" on.

With the first method, BoilWaterIsIntitial, we ask the tool to prove that there is no state from which we can transition into BoilWater:

static public void BoilWaterIsInitial(CookPasta someState)
{
  var next = CanTransition(someState, CookPasta.BoilWater);
  Contract.Assert(!next, "there is no way to transition to boiling water");
}

Similarly, we can ask the tool to prove that there is successor for Eat.

static public void EatingIsFinal(CookPasta someOtherState)
{
  var next = CanTransition(CookPasta.Eat, someOtherState);
  Contract.Assert(!next, "Once you eat your pasta, nothing left to do");
}

Nevertheless, if we ask whether Strain is final, cccheck will tell that it is not:

static public void StrainIsFinal(CookPasta someOtherState)
{
  var next = CanTransition(CookPasta.Strain, someOtherState); 
  Contract.Assert(!next, "We cannot prove it, as it is false");
}

d:\tmp\Pasta\CookPasta.cs(58,9): warning : CodeContracts: assert unproven

What's the magic behind? There is no magic. The static analyzer will infer the inputs under which CanTransition returns true, and then it uses this information to prove (or disprove) the assertion. If you are curious to see what the inferred postcondition looks like, add "-infer methodensures" to the extra static checker options box in VS.

The problem. Suppose that we want to write a program to cook pasta. Cooking pasta is a simple. First we let the water boil, we add the pasta, we stir, and eventually we strain. We define an enum CookPasta to remember in which state we are and a Next method to tell us what’s coming next. The code is straightforward:

enum CookPasta { BoilWater, AddPasta, Stir, Strain, Done }

public CookPasta Next(CookPasta state)
{

  switch(state)
  {
    case CookPasta.BoilWater:
      return CookPasta.AddPasta;

    case CookPasta.AddPasta:
      return CookPasta.Stir;

    case CookPasta.Stir:
      return CookPasta.Strain;

    case CookPasta.Strain:
      return CookPasta.Done;

    case CookPasta.Done:
      return CookPasta.Done;

    default:
      throw new Exception("Unknown pasta state!");
   }
}

We added a throw statement to make the C# compiler happy - it would refuse to compile our code otherwise. However, we soon realize that our algorithm to cook pasta is wrong. We forgot a fundamental step: We need to add salt to the boiling water! Therefore we add a case to the enum case:

enum CookPasta { BoilWater, AddPasta, AddSalt, Stir, Strain, Done }
 

But now suppose that we forgot to update the Next method (in real code there can be tenths of places to be updated). What is going to happen? An exception ("Unknown pasta state") will be thrown at runtime. But we love compile time analysis, so is there a way to have the static checker warn us that we forgot one case?

The solution. It is straightforward: All we need is to add an Assert(false) in the default branch:

default:
  Contract.Assert(false); // The static checker should prove it unreachable
  throw new Exception("Unknown pasta state!");

We are essentially asking the static checker to prove false, which is of course impossible. In fact, we get:

 warning : CodeContracts: This assert, always leading to an error, may be reachable. Are you missing an enum case?

If we fix the code, adding the missing cases

case CookPasta.BoilWater:
  return CookPasta.AddSalt;

case CookPasta.AddSalt:
  return CookPasta.AddPasta;

then cccheck will not emit any warning. Why? Did it just proved the impossible (false)? Actually no, it proved that there is no execution reaching the Contract.Assert(false), as we covered all the cases for CookPasta.

The improved solution. Nevertheless, there is something a little bit ugly about the above solution, as some friend in Microsoft product groups noticed. We should write two lines of code, an assert for the static (and dynamic) checker, and a throw instruction for the C# compiler. Is there a better way of doing it? The trick is to defined an helper class CodeContractsHelpers with an helper function ThrowIfReached.

In the switch statement we write something like

default:
  throw CodeContractsHelpers.ThrowIfReached("Unknown pasta state!");

Now it is a matter of defining ThrowIfReached. This is pretty easy:

  public static class CodeContractsHelpers
  {
    [ContractVerification(false)]
    public static Exception ThrowIfReached(string s)
    {
      Contract.Requires(false);

      return new Exception(s);
    }
  }

The helper method returns a new exception object. It has a precondition "false", i.e., it requires to never be called. When analyzing the Next method the static checker will turn the Contract.Requires(false) into a Contract.Assert(false), so that we have the same behavior as above - The static checker will complain if we miss one (or more) case. Finally we use the [ContractVerification(false)] to turn the verification of this helper off.

Is it sound? Are we 100% guaranteed that our switch case is comprehensive, and as a consequence no execution will ever reach the default branch? In the usual case yes. If the programmer only uses the defined enums, then everything is fine. However, C# allows to forge new enum values like this

    public const CookPasta AddOil = (CookPasta)(-1);

and invoke Next like this (with no type-checking error from C#):

var next = Next(AddOil);

Luckily the static checker will realize there may be a problem, and it will warn about it:

warning : CodeContracts: The actual value is not one of those defined for this enum. Forgotten [Flag] in the enum definition?

In this first post, I'd like to explain the difference between the two concepts, and guide you in the usage of one or the other kind of contract.

Intuitively, Assert is something that you expect the static checker be able to prove at compile time, whereas Assume is something that the static checker can rely upon, but it will not try to prove. At runtime Assert and Assume behave the same: If the condition is false, then the program fails – how it fails (e.g., throwing an exception, opening a dialog box, etc. can be completely customized with CodeContracts).  

For instance, in the code below we expect that on loop exit that the value of i is 1001, and we ask the static checker to prove it.

     public void Count()
    {
      var i = 0;
      var j = 1000;
      while (j >= 0)
      {
        i++;
        j--;
      }
      Contract.Assert(i == 1001);
    }

In fact, the static analyzer infers that after the loop:

i + j == 1000 and j == -1

and it deduces that the assertion holds. 

Intermezzo: Try this example with the CodeContracts static checker and you see that it can prove the assertion. Then try to change the assertion, let's say to i == 1000, and it will complain that it is false. How the tool infer the loop invariant? Stay tuned, I will post about it…

Nevertheless, there is so much that every static program analyzer or verifier in the world knows or can infer (do you remember Turing?). There are cases where we need to help the tool by telling “please believe me, at this program point this condition is true, so do not try to prove it”. In such cases you will use Contract.Assume.

As an example, let us imagine that we have a sensor that reads the room temperature, but it does it using the Kelvin temperature scale. The Kelvin temperature scale is great for science (values are always non-negative, the smallest values is the absolute zero) but not so much for humans (70K may seem very hot, but actually it’s extremely cold…). So, let’s write a small function to read from our sensor and convert to Celsius. We are careful programmers, and we also want to document, via a postcondition, the smallest value our implementation can return. Our code looks like

// No contract
extern double ReadTheTemperatureInKelvinFromSensors();

public double GetTemperatureInCelsius()
{
    Contract.Ensures(Contract.Result<double>() >= -273.15);

    var kelvin = ReadTheTemperatureInKelvinFromSensors();
           
    return kelvin - 273.15;
}

Then, we want to prove it correct. So we run the static checker. Which complains that it cannot prove the postcondition. Why is this? The problem is that the static checker has no knowledge about what  ReadTheTemperatureInKelvinFromSensors does, and in particular it does not know that it always returns a non-negative value. We make this assumption explicit, to the static checker, but also to the human who reads the code:

public double GetTemperatureInCelsius()
{
    Contract.Ensures(Contract.Result<double>() >= -273.15);

    var kelvin = ReadTheTemperatureInKelvinFromSensors();
     
    Contract.Assume(kelvin >= 0, "Physical world assumption - Checked at runtime");
     
    return kelvin - 273.15;
}

The static checker will not try to prove that kelvin is non-negative, it will assume it and as a consequence it will prove the postcondition will never be violated. But what happens at runtime if there is a failure in the sensor and it will return a "crazy" value? Well, as we made the assumption explicit, the execution will stop at Assume(kelvin >= 0) immediately pointing out the place where something went wrong...