VCC Issue Tracker Rss Feed

Created Issue: objects should be able to own open objects [6647]

erniecohen — Sun, 24 Mar 2013 17:28:58 GMT

Consider the problem of transferring ownership of an open object from one thread to another. Currently, there is no decent way to do this, because the usual method (transferring ownership through an intermediate object) requires the transferred object to be closed.

This is yet another argument that we should get rid of the requirement that objects owned by non-threads should be closed.

Commented Issue: Problem with installation in Visual Studio [6646]

AntonDergunov — Tue, 19 Mar 2013 15:01:31 GMT

I have installed this release and I am getting the following error "Exception has been thrown by the target of an invocation" when I run VS 2010 or VS 2012. I have uninstalled VCC and the problem is gone. Is it possible to workaround this problem somehow? Should I try an earlier release? I am running Win 7.
Comments: I am talking about the latest release: v2.3.10214.0

Created Issue: Problem with installation in Visual Studio [6646]

AntonDergunov — Tue, 19 Mar 2013 15:01:03 GMT

Edited Issue: unwrapping object listed in atomic clause gets error [6645]

erniecohen — Mon, 25 Feb 2013 01:50:43 GMT

The following fails with the error:
"assertion 's is closed (for atomic(...)) did not verify."
It gets the same error if s is made _(read_only).

_(typedef struct S {} S)
void test(_(ghost S ^s))
_(requires \wrapped(s))
_(writes s)
{
_(atomic s) {
_(unwrap s)
_(begin_update)
}
}

Created Issue: unwrapping object listed in atomic clause gets error [6645]

erniecohen — Mon, 25 Feb 2013 01:49:20 GMT

Created Issue: \mine() should allow \objset [6644]

erniecohen — Mon, 11 Feb 2013 20:56:56 GMT

currently, \mine can take a list of objects, but not an \objset.

Created Issue: triggering error when using meta fields in def functions [6643]

erniecohen — Tue, 05 Feb 2013 10:43:12 GMT

the following function definition gets the error

"trigger must mention all quantified variables, but does not mention: Q#__vcc_state$1^3.42#tc1#344"

_(def \bool closed(\object o) {
return o->\closed;
})

Created Issue: \writable should be allowed in postconditions [6642]

erniecohen — Mon, 04 Feb 2013 18:41:10 GMT

consider a function with a contract that takes an object argument which it writes, and returns either that object or another, fresh object. In either case, the returned object will be writable for the caller, but currently the parser doesn't allow this. We could strengthen the contract to make the returned object \fresh, but then we would have to actually write to y, which may involve its own drawbacks. (currently, we can hack around this by wrapping y in something and unwrapping, but that's sort of gross).

Created Issue: strongest solutions for recursive predicates [6641]

erniecohen — Mon, 07 Jan 2013 21:29:46 GMT

VCC currently requires that pure functions terminate. This is inconvenient for predicates used to define recursive data structures. For example, we would like to define the nodes of a list with a definition like

node(n,x) == n && (x==n || node(n->nxt,x))

or proper lists as

list(n) == (n ==> list(n->nxt) && !node(n,n->nxt))

For VCC's purposes, it's not important that we get the strongest solution, just that we get a solution, and thanks to monotonicity, we can guarantee a solution exists.

Created Issue: \naturals not constrained to be nonnegative [6640]

erniecohen — Mon, 07 Jan 2013 18:17:26 GMT

The following fails to verify without the loop invariant that q >= 0:

_(void div(\natural n, \natural d _(out \natural q) _(out \natural r))
_(requires d > 0)
_(ensures n == q * d + r && r < d)
_(decreases 0)
{
q = 0;
r = n;
while (r >= d)
_(invariant n == q *d + r)
//_(invariant q >= 0)
_(decreases r)
{
q = q + 1;
r = r - d;
}
})

Created Issue: postconditions for _(def) functions [6639]

erniecohen — Sat, 05 Jan 2013 21:37:41 GMT

Officially, a _(def) function should be a pure ghost function with an implicit postcondition derived from its body. This means that it should accommodate additional postconditions. However, while such postconditions are proved, they are currently not available for use when the function itself is called. For example, the following fails to verify, but verifies if the _(def) is replaced with a _(ghost _(pure) (modulo the bug giving the spurious warning about the cycle of pure function calls):

_(def \natural test(\natural i) {
return (i ? 1 + test(i-1) : 0);
})

_(def \bool testId(\natural i)
_(ensures test(i) == i)
_(ensures \result)
{
if (i) _(assert testId(i-1));
return \true;
})

Edited Issue: spurious warning on cyclic pure function with termination measure [6546]

erniecohen — Sat, 05 Jan 2013 21:08:03 GMT

Commented Issue: spurious warning on cyclic pure function with termination measure [6546]

erniecohen — Sat, 05 Jan 2013 21:05:32 GMT

If a pure function has a _(decreases) clause, there is no reason to give a warning for a cycle in pure function calls. (Indeed, we should only give a warning if there is a cycle of functions, none of which has a measure.) We could leave the warning in when termination checking is turned off via a switch.
Comments: (Don't know why I forgot to reply to Michal's comment before.) I don't think we can deprecate _(pure) functions, just _(pure) functions without bodies and (possibly implicit) termination measures.

Commented Issue: perf problem on function call framing [6638]

erniecohen — Thu, 20 Dec 2012 19:16:23 GMT

Verifying the following exhausts memory:

void assign(int v, int* pv)
_(writes pv)
_(ensures *pv == v);

void test();

void foo()
{

int local_a;

assign(3, &local_a);

test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
test();
}

Comments: Note, the verification time appears to be growing exponentially in the number of calls to test().

Created Issue: perf problem on function call framing [6638]

erniecohen — Tue, 18 Dec 2012 19:06:37 GMT

Created Issue: parser dies on conjunction of naturals [6637]

erniecohen — Tue, 11 Dec 2012 20:26:12 GMT

The following bombs VCC:

void test() {
_(ghost \natural x)
_(assert x && x)
}

Created Issue: the class of objects should be finite [6636]

erniecohen — Mon, 10 Dec 2012 11:44:59 GMT

One of the challenges of a first-order approach to data structures is guaranteeing termination. For example, one way to formulate data structures is to maintain the reachability relation and insist that it is acyclic. However, this is not enough to guarantee that functions traversing the structure terminate. We have usually coped with this by maintaining additional information, such as the maximum path length from each node.

A somewhat simpler way to cope with the finiteness problem is to simply assert that every set of concrete objects is finite. It might even pay to do the same for ghost objects, even though we've generally hoped to keep alive the flexibility to have an infinite number of objects at the same time, e.g. if we are creating an infinite number of ``virtual'' objects all at once. A third possibility, that does not require changing the logic, is to define a finiteness predicate (on \objset s), prove suitable properties about it (e.g., that it is closed under the obvious operations), and use it explicitly in object invariants.

Note that once we have finiteness, maintaining reachability generally gives us all we need for data structures that can be embedded in DAGs, since the number of reachable nodes gives us a well founded measure for functions that traverse the structure.

Created Issue: objects should be allowed to own open objects [6635]

erniecohen — Wed, 05 Dec 2012 14:34:46 GMT

We have always maintained the invariant that only threads could own open objects. This has the advantage that we avoid silly errors arising from someone forgetting to put in an object invariant that says that something it owns is closed. The disadvantage, however, is that it makes objects second-class citizens wrt ownership. For example, if you are doing surgery on a data structure, you might want to capture an intermediate state of that structure with an object invariant that talks about the unwrapped parts of the data structure. More generally, being open is the natural way to indicate that we are using an object as plain old data, so that we don't have to worry about the sequential uses of the data conflicting with its regular invariants.

The natural generalization is to allow objects to own open objects, and to use essentially the same behavior as with threads, namely that all changes to fields of open objects are owner-approved. This allows the owner of an open object to say whatever he wants about the fields of the open object.

Created Issue: change def of _(always) to allow derivative claims [6634]

erniecohen — Wed, 21 Nov 2012 14:14:21 GMT

Currently, _(always c,p) does not include a writes clause for c. However, a function will often take a derivative claim on c or change its ownership temporarily, either of which require writing c, so the typical spec for a claim is

_(always c, p)
_(writes c)
_(ensures \unchanged(c->\claim_count))

Since there are essentially no use cases where we want a function to change the claim count of a claim spec'd with _(always), I propose that we should just make the above contract the new definition of _(always c,p), i.e. define _(always c,p) as

_(maintains \wrapped(c) && \claims(c, p))
_(writes c)
_(ensures \unchanged(c->\claim_count))
_(maintains \assume(active_claim(c)))

. Does anybody know of any legacy code that this would break?

Created Issue: invariants that forbid unwrapping [6633]

erniecohen — Thu, 15 Nov 2012 16:49:06 GMT

The following fails to verify, because the second invariant forbids unwrapping (in the case that the succ of a List points to itself):

typedef struct List List, *PList;

typedef struct List {
volatile PList succ;
_(invariant \on_unwrap(\this,\false))
_(invariant succ->\closed)
} List;

The purpose of the unwrapping check is to minimize the invariants that have to be checked on an unwrap.
However, in this case, the second invariant doesn't have to be checked, because an unwrap that breaks the second invariant also breaks the first invariant, which is checked. So we should be changing the unwrapping check so that it assumes that the unwrap preserves all of the checked invariants.