Modular Handling of Loops by Means of Procedure Calls. In the literature of program contracts (e.g., Xxxxxxxx et al. [2002], Xxxxxxx et al. [2006], and Xxxxxxx et al. [2004]), either of the following two approaches are taken to handle loops: (1) loop unrolling, where the behavior of each loop is underapproximated by unrolling this loop a finite number of times; or (2) a modular approach using loop invariants, where each loop is associated with its loop invariant that takes a role of the contract for this loop. When using change contracts instead, both approaches can be taken again with adjustments. First, loop unrolling is straightforward. One simply needs to unroll each loop of both versions the same number of times. Meanwhile, substantial adjustment is necessary for the second modular approach. Note that a loop invariant is the program contract for the corresponding loop in the sense that it describes the behavior of an individual loop. However, what we need is the change contract of a loop that describes how the behavior of this loop changes across versions. We use a different specification than a loop invariant to describe the changes of a loop for the same reason that we use a change contract instead of a program contract to describe the changes of a procedure. − → = Figure 12 shows how we specify the behavioral changes of a loop. First, Figure 12(a) shows the two versions of procedure sum. The only difference between them is the operators used for the loop exit conditions (i.e., i < k i < k). As a result, the sum of v1 adds the numbers from 1 to k 1, while its counterpart of v2 adds the numbers from 1 to k. The value of k is given as a parameter of sum. Notice that we annotate these loops with “//@ set s=sum loop(k);”. Apparently, this annotation does not express a loop invariant. It is instead an assignment statement.10 This assignment is used by our static checker and not executed at runtime. The left- hand side of this assignment is variable s whose value changes over the loop. The right- hand side expression “call sum loop(k)” calls an auxiliary specification-purpose procedure sum loop. This procedure sum loop does not exist in the original source code. We use these new-style specifications of loops in interpreting loops in a modular way. Our static checker skips over loops. Instead, it uses the specifications of loops. Since each of these specifications calls a procedure, we can reuse our modular handling of procedure calls. = \ \ \ More specifically, in our example, we assign to a new procedure sum...
