This document provides an overview of Spec#, which is a specification language that extends C# with support for design by contract features like preconditions, postconditions, and object invariants. This allows programs to be verified for correctness. The architecture of Spec# compiles the specifications into verification conditions that are passed to an automatic theorem prover called Boogie to formally prove properties about programs. Spec# aims to make program verification practical and cost effective for developing high quality software.

1. Program
Verification
Using Spec#

2. Motivation
• Prove correctness of
the program
• Cost effective way to
develop and maintain
high-quality
software.

3. Road Map
• Design by Contract
• Spec# Architecture
• Demo

4. Design by Contract
• First appeared in Eiffel
• formal, precise and
verifiable interface

5. Pre Conditions
class ArrayList {
public virtual void Insert( int index , object value)
requires 0 <= index && index <= Count; //Pre condition
{ }

6. Post Conditions
class ArrayList {
public virtual void Insert( int index , object value)
requires 0 <= index && index <= Count;
ensures Count == old(Count) + 1; //Post conditions
ensures value == this[index];
{ }

7. Not Enough
• Method Constructs
not enough
• Enforce constraints on
private members?
• Abstraction Violation?
• How to ensure object’s
state?

8. Object Invariants
class SortOrder {
ItemsList[ ]! randomList;
ItemsList[ ]! sortedList;
invariant randomList.Length == sortedList .Length;

9. Blame Game
• Require failure =>
Blame the
method caller (Client)
Ensure failure =>
Blame the
method implementor
(Provider)

10. Spec# Architecture
Spec# Compiler
Verification Code Generator (Boogie)
Automatic Theorem Prover (Boogie)

11. Why extend C#???
• Non Null Types
• Method Contracts
• Checked / Unchecked
Exceptions

12. Non Nullable Types
public class Program
{
public static void Main(string![]!args)
{
for (int i=0; i< args.Length; i++)
{
Console.WriteLine(arg[i]);
}
Console.ReadLine();
}
}

13. Exceptions
Failures
Provider
Admissible
Observed
Program
Errors
Client

14. Assertions???
• Why just simple assertions can’t help?
• Callbacks, Multi Threads, Inheritance

15. Code Comparison
C#
public class SomeClass
{
public SomeClass()
{
}
public int SomeMethod(int i)
{
return 50/i;
}
}
Spec#
public class SomeClass
{
public SomeClass()
{
}
public int SomeMethod(int i)
requires i != 0;
{
return 50/i;
}
}

16. IL (C#)
.method public hidebysig instance int32 SomeMethod(int32 i) cil managed
{
// Code size 5 (0x5)
.maxstack 8
IL_0000: ldc.i4.s 50
IL_0002: ldarg.1
IL_0003: div
IL_0004: ret
} // end of method SomeClass::SomeMethod

17. IL (Spec#)
.method public hidebysig instance int32 SomeMethod(int32 i) cil managed{
.custom instance void
[System.Compiler.Runtime]Microsoft.Contracts.EnsuresAttribute::.ctor(string) = smthng
.locals init (int32 V_0, class
[System.Compiler.Runtime]Microsoft.Contracts.ContractMarkerException V_1, int32 V_2)
// Some Usual Operations
.try
{
….
IL_0016: ldstr "Postcondition 'i != 0' violated from method
classLibrary1.SomeClass.SomeMethod(System.Int32)'"
IL_001b: newobj instance void
[System.Compiler.Runtime]Microsoft.Contracts.EnsuresException::.ctor(string)
IL_0020: throw
….
} // end .try
….
IL_002e: ret
} // end of method SomeClass::SomeMethod

18. Runtime Checks
• Preconditions and
postconditions are
turned into inlined
code
• Performance
• Extra methods and
fields in the compiled
code

19. Automated Theorem Prover
• BoogiePL
• Simplify Theorem Prover
• Propositional Calculus

20. Demo