Code contracts: static checking fails on IEnumerable.Min

Question

I get some warnings on the following code containing code contracts.

public static int Min(IEnumerable<int> set)
{
    Contract.Requires(set != null);
    Contract.Requires(set.Any());

    Contract.Ensures(Contract.ForAll(set, x => x >= Contract.Result<int>()));

    int min = set.Min();

    return min;
}

static void Main(string[] args)
{
    Console.WriteLine(Min(new int[] {3,4,5}));
    Console.WriteLine(Min(new int[] {})); // should fail
}

I get the following warnings:

Requires unproven: set.Any() on Min(new int[] {3,4,5})

Ensures unproven: Contract.ForAll(set, x => x > Contract.Result<int>())

Two questions:

My postcondition states x >= Contract.Result(), but the "ensures unproven" warning states x > Contract.Result(). (Greather or equal vs. Greather) How can this happen?
Why can't set.Any() proven in the above statement?

Thank you in advance.

The `new int[] {3,4,5}` statement is executed at runtime. At compile time, there is no way for the contract checker to know what the contents of *set* are, so it can't verify that set contains any data, much less that Min() can return meaningful results — Panagiotis Kanavos, Dec 12 '12 at 11:40
Thank you. I've added Contract.Assume(arr != null && arr.Any()); before I pass the array to Min(). But I still don't have an idea why ensures fails and why the warning states (x > Contract.Result()) rather than (x >= Contract.Result()) as stated in the code. — mbue, Dec 12 '12 at 11:50
If you change set from IEnumerable to int[], the checker succeeds ... — Panagiotis Kanavos, Dec 12 '12 at 12:07
Seems strage. Still doesn't work here. However, I now found the reason why the warning stated an assumption not stated in the code. The code contracts cache (can be disabled via project settings) was not up to date. Anyway: When I change the type of set to int[], I still get the warning: "ensures unproven: Contract.ForAll(set, x => x >= Contract.Result())". I did a clean/rebuild... — mbue, Dec 12 '12 at 12:23

score 1 · Answer 1 · answered Dec 12 '12 at 12:22

1

The Ensures clause isn't valid for all IEnumerable's to begin with. You could write an IEnumerable that returns one sequence the first time it is enumerated (e.g. 1, 2, 3) and another list the second time (e.g. 0). It is an interface with arbitrary implementations.

IEnumerable's usually have a lot of (potentially generated) stuff going on under the covers. I don't think CC can see through that, even if the concrete runtime type was somehow known.

Is CC even capable of heuristically reasoning about IEnumerable's? That would be new to me. It would have to assume that a sequence does not change if enumerated multiple times (which is trivially false in case of database queries).

Let me point out as a subjective side note that I have found the CC checker to be far too limited to be of any use. It causes insane amounts of trouble to prove interesting properties. It does not cope with abstractions well.

answered Dec 12 '12 at 12:22

usr

168,620
35
240
369

Thank you very much for this statement, your last sentence pretty much reflects my current thoughts... Spoken honestly, the static checker ist the only real value I see regarding code contracts. Having runtime checks on Contract.Requires/Contract.Ensures rather seems like syntacical sugar replacing "if(foo) throw Exception"-statements. So my question is: if you don't see a real value with the static checker, what real benefits does Code Contracts offer? – mbue Dec 12 '12 at 12:29
@mbue I investigated them for their coolness factor and because I believe in contract based development. Unfortunately, CC is a net loss in productivity. I have R# generate argument nullness checks for me in case I need them and I sprinkle asserts where they make sense.; You might want to check out Microsoft Pex which is *awesome* to debug code. It only works if the code under test is isolated from external dependencies (IO). But in that case it has a good chance to find *all* bugs (defined as a failing test). It has no false positives. – usr Dec 12 '12 at 12:34

score 0 · Answer 2 · answered Dec 12 '12 at 12:47

There is no way for the STATIC code checker to determine that set contains any data. If you think about it, the checker doesn't know what the various methods and properties do, unless some contracts are defined inside the methods themselves.

In your case, the checker doesn't know what the results of the extension methods Any() or Min() may be, so it can't validate any Requires and Ensures.

You can get fewer warnings by changing the type of the parameter, but in the end the code checker still can't ensure that your code can fulfill Min(...)'s requirements.

If you change the type to int[] or List, some of the warnings MAY disappear. The following code returns no warnings:

    public static int Min(List<int> set)
    {
        Contract.Requires(set != null);
        Contract.Requires(set.Count>0);


        Contract.Ensures(Contract.ForAll(set, x => x >= Contract.Result<int>()));

        int min = set.Min();

        return min;
    }

    static void Main(string[] args)
    {

        Console.WriteLine(Min(new List<int> { })); // should fail
        Console.WriteLine(Min(new List<int> { 3, 4, 5 }));
        Console.ReadKey();
    }

Of course, if you run this code it will fail with an exception, so perhaps the code checker is smart enough to detect this.

If you keep the original order, you still get a warning:

        Console.WriteLine(Min(new List<int> { 3, 4, 5 }));
        Console.WriteLine(Min(new List<int> { })); // should fail

In both cases you also get some crazy suggestions, like adding Contract.Ensures(false) in Main().

Code contracts: static checking fails on IEnumerable.Min

2 Answers2