The program http://rise4fun.com/Dafny/tzzD is quickly verified in online-Dafny, but not in MVS-Dafny.
Please, some help?
Paqui
Comments: The discrepancy you found is due to a bug in the Dafny version on rise4fun. The bug was fixed in changeset c41a160e4814: "Fix bug in translation of 'new' for arrays". So, the behavior you're seeing in Visual Studio is the correct one. Let me describe what's going on in your two programs above. In the Enqueue example, the assertion a[0]==5 on line 38 is verified, because c[0] is assigned 5 on line 30 and a is aliased with c on line 32. Line 39 makes a call to Enqueue. Note that the specification of Enqueue says exactly what the post-value of Contents is, but all that is known about a after the call is that ValidQueue() is satisfied. This specification allowed Enqueue to allocate a new array a and to place the Contents elements anywhere in that new array. Before the call to Enqueue, Contents==[5,4] and these two elements are stored in array a as follows: a.Length==2, a[0]==5, a[1]==4, where n==0 and m==2. Upon return from Enqueue, the specification allows the following state: Contents == [5,4,7] a.Length==7145 n == 2145 m == 2148 a[2145] == 5 a[2146] == 4 a[2147] == 7 Therefore, the assertions on lines 40 and 45 are not guaranteed to be correct. Dafny (now :)) produces an error, as it should. Methodologically, I would say that client code (like Test()) should not make assertions about the internal state of the queue (that is, about array a and variables m and n), only about Contents, since the values of a, m, n are implementation dependent. By the way, the values I showed above are what the Verification Debugger tells me in Visual Studio (except a[2147] and Contents[2], which apparently were not necessary to demonstrate the error). If you click on the red circle in Visual Studio, the Verification Debugger will pop up. If you then click on a blue circle before the call to Enqueue, you'll see the state at that time, and if you click on a blue circle after the call to Enqueue, you'll see the state then. In your second program above, this.m==2 before the call to Test. Test has a modifies clause "this", so it is allowed to modify the value of this.m. For this reason, you cannot prove m==3 on line 17, since the specification of Test allows Test to change this.m to any value whatsoever. When you run the program, it so happens that the given implementation of Test will change this.m to 3, and that is the value you see printed. Thanks for the bug report. The Dafny version on rise4un will soon be updated to reflect the fix. Rustan
Please, some help?
Paqui
Comments: The discrepancy you found is due to a bug in the Dafny version on rise4fun. The bug was fixed in changeset c41a160e4814: "Fix bug in translation of 'new' for arrays". So, the behavior you're seeing in Visual Studio is the correct one. Let me describe what's going on in your two programs above. In the Enqueue example, the assertion a[0]==5 on line 38 is verified, because c[0] is assigned 5 on line 30 and a is aliased with c on line 32. Line 39 makes a call to Enqueue. Note that the specification of Enqueue says exactly what the post-value of Contents is, but all that is known about a after the call is that ValidQueue() is satisfied. This specification allowed Enqueue to allocate a new array a and to place the Contents elements anywhere in that new array. Before the call to Enqueue, Contents==[5,4] and these two elements are stored in array a as follows: a.Length==2, a[0]==5, a[1]==4, where n==0 and m==2. Upon return from Enqueue, the specification allows the following state: Contents == [5,4,7] a.Length==7145 n == 2145 m == 2148 a[2145] == 5 a[2146] == 4 a[2147] == 7 Therefore, the assertions on lines 40 and 45 are not guaranteed to be correct. Dafny (now :)) produces an error, as it should. Methodologically, I would say that client code (like Test()) should not make assertions about the internal state of the queue (that is, about array a and variables m and n), only about Contents, since the values of a, m, n are implementation dependent. By the way, the values I showed above are what the Verification Debugger tells me in Visual Studio (except a[2147] and Contents[2], which apparently were not necessary to demonstrate the error). If you click on the red circle in Visual Studio, the Verification Debugger will pop up. If you then click on a blue circle before the call to Enqueue, you'll see the state at that time, and if you click on a blue circle after the call to Enqueue, you'll see the state then. In your second program above, this.m==2 before the call to Test. Test has a modifies clause "this", so it is allowed to modify the value of this.m. For this reason, you cannot prove m==3 on line 17, since the specification of Test allows Test to change this.m to any value whatsoever. When you run the program, it so happens that the given implementation of Test will change this.m to 3, and that is the value you see printed. Thanks for the bug report. The Dafny version on rise4un will soon be updated to reflect the fix. Rustan