Class-local object invariants 6/23/2018 6:05 PM Class-local object invariants K. Rustan M. Leino Microsoft Research Redmond, WA, USA Angela Wallenburg Chalmers University of Technology Göteborg, Sweden 20 Feb 2008 ISEC 2008 Hyderabad, India © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Program verification Reasoning about object-oriented software involves object invariants An object invariant describes the steady state of an object Because of call-backs, it is necessary to keep track of when object are in their steady state public class MyClass { int x, y; // invariant x < y; public int M() { int d = 100 / (y - x); // expose (this) { y++; x++; // } return d; } public MyClass(int k) // requires 0 < k; { x = 0; y = k; } public class SomeOtherClass { public static void P(MyClass c) { c.M(); DEMO 0: 0. add precondition to M: x < y 1. remove it, and add invariant x < y 2. add precondition to ctor: 0 < k 3. reverse order of x++/y++ (inv is temporarily violated) 4. add call to SomeOtherClass.P(this) 5. undo (3) and (4) Demo 0

Program verification Reasoning about object-oriented software involves object invariants An object invariant describes the steady state of an object Because of call-backs, it is necessary to keep track of when object are in their steady state …but first, a word from our sponsor Spec# is a programming system that emphasizes program specifications. The Spec# language is a superset of the object-oriented .NET language C# 2.0. The system can be downloaded from Microsoft Research, http://research.microsoft.com/specsharp. Demo 0

Boogie methodology Idea: Explicitly keep track of whether an object is in its steady state Done by adding a special field inv to each object, such that: (o  o.inv  Inv(o)) The inv field is changed by a special program statement: the expose block DEMO 1: 0. add expose statement 1. add call to P (results in precondition violation – explain default preconditions) Demo 1

Subclassing Each class can declare its own invariant Each class gets its own inv field (o,T  o.invT  Inv(o, T)) Expose block operates on one invT field public class Superclass { protected int x, y; invariant x < y; public Superclass() { x = 0; y = 10; } public virtual int M() { int d = 100 / (y - x); y++; x++; return d; } public class Subclass : Superclass { /* int z; invariant z < 8; public override int M() { expose ((Superclass)this) { x++; y++; } z = (z + 1) % 8; return base.M(); */ DEMO 2: 0. add: int z; … return base.M(); (but without the expose statement) 1. add: expose (this) … (to show how expose selects class/inv field) 2. change to: expose ((Superclass)this) … Demo 2

Exposing subclasses class T : object { … } class U : T { … } class V : U { … } void M(U u) { expose (u) { … } expose ((T)u) { … } } V U T object

Exposing subclasses class T : object { … } class U : T { … } class V : U { … } void M(U u) { expose (u) { … } expose ((T)u) { … } } V U T object

Exposing subclasses class T : object { … } class U : T { … } class V : U { … } void M(U u) { expose (u) { … } expose ((T)u) { … } } V U T object

Invariants that mention superclass fields Modular verification: each “module” is verified independently, using only the specifications of other modules To support modular verification, changes in a superclass must be consistent with all possible subclass invariants! using Microsoft.Contracts; public class T { public T() ensures x == 0; { x = 0; } /*[Additive]*/ protected int x; invariant 0 <= x; /*[Additive]*/ public virtual void Inc() { /*additive*/ expose (this) { x++; } } public class U : T { protected int y; //invariant x <= y; public U() { y = 0; } /*[Additive]*/ public override void Inc() { /*additive expose (this) {*/ base.Inc(); /*}*/ DEMO 3: 0. add invariant x <= y in U 1. Show inv x… is not admissible admissible Demo 3

Inter-class invariants class T : object { … } class U : T { int x; … } class V : U { int y; invariant x ≤ y; … } V void M(U u) { expose (u) { x++; } } U T object

Additive behavior By always exposing an entire suffix of class frames (one frame at a time), we can allow additive invariants void M(U u) { expose ((V)u) { expose (u) { x++; } } } V U DEMO 4: 0. add [Additive] to x 1. add additive in T 2. add [Additive] to T.Inc 3. add [Additive] to U.Inc 4. add additive expose to U.Inc T Demo 4 object

Implementation Allow both additive and local invariants and expose blocks Only one local expose (per object) at a time o typeof(o) “o is in steady state” ≡ o.inv = o.localinv = typeof(o) if f is a field declared in class T with superclass S, then o.f is allowed to be modified if: (o.inv <: T)  o.localinv = S o.inv o.localinv object

Contributions An integration of class-local and additive invariants Experience results >6000 lines of code Class-local invariants are used exclusively Our encoding of constructors use additive behavior, but perhaps this could be encoded differently

Aggregate objects class U : T { rep C p; invariant p.x < 100; … } class V : U { invariant p.x == 20; … } not supported V U p x T object

Summary and conclusions Class-local invariants can be used together with additive invariants Additive invariants are rarely used Implemented in Spec# and its program verifier Boogie Open issue: nice way to allow invariants to dereference fields declared in superclass Download Spec# and Boogie from here http://research.microsoft.com/specsharp