7

I'm having an argument with the CodeContracts static analysis tool.

My code:

Screenshot

(ASCII version)

The tool tells me that instance.bar may be a null reference. I believe the opposite.

Who is right? How can I prove it wrong?

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
dtb
  • 213,145
  • 36
  • 401
  • 431
  • 2
    Off Topic, but could you tell me what visual studio theme you are using? – Justin Apr 21 '10 at 01:23
  • 1
    @Justin: just the default vs2010 theme with my own custom text color scheme (see edited post). Why are you asking? – dtb Apr 21 '10 at 01:38
  • I've just been looking to change my own visual studio color scheme lately and really like your's. I was wondering if you had downloaded it somewhere. – Justin Apr 21 '10 at 01:43
  • @Justin: Uhm... the "theme" before my edit was just the default StackOverflow syntax highlighting scheme (which, I believe, is based on the default Visual Studio text color scheme). You can generate nice color schemes for Visual Studio using this tool: http://www.frickinsweet.com/tools/Theme.mvc.aspx – dtb Apr 21 '10 at 01:46
  • Thanks, I probably look a little crazy right now. It turns out I installed a google chrome extension yesterday that highlights syntax and forgot about it. Haha. Sorry for wasting your time. And thanks for the link! – Justin Apr 21 '10 at 01:53

5 Answers5

2

CodeContracts is right. There is nothing stopping you from setting instance.bar = null prior to calling the BarLength() method.

EMP
  • 59,148
  • 53
  • 164
  • 220
  • 2
    But I'm not setting `instance.bar = null` anywhere and `instance.bar` is private, so it can't be null, right? – dtb Apr 20 '10 at 23:36
  • Yes, so I suppose you are right if that's the entire code. Its static analysis is probably not smart enough to figure out whether you ever set the value to null or not, so it assumes that you might. I don't know what lengths it goes to to check for that - if any. – EMP Apr 20 '10 at 23:39
  • How do I convince it that `instance.bar` is never `null`? Making `bar` read-only and adding `Contract.Ensures(bar != null);` to the constructor doesn't do the trick. `Contract.Assume(instance.bar != null);` in `BarLength()` works but looks ugly. – dtb Apr 20 '10 at 23:43
  • Adding a class invariant doesn't help as well. – dtb Apr 20 '10 at 23:47
  • 1
    Checking for null before accessing it would convince it (there's a small runtime cost to that, of course). – Noah Richards Apr 21 '10 at 00:21
  • "There is nothing stopping you from setting instance.bar = null prior to calling the BarLength() method." ... except for the fact that bar is readonly? – Robert Noack Jan 09 '15 at 18:35
2

Your code includes a private static initialized instance:

private static Foo instance = new Foo();

Are you assuming that this means the instance constructor will always have run before access to any static method, therefore ensuring bar has been initialized?

In the single threaded case, I think you're right.

The sequence of events would be:

  1. Call to Foo.BarLength()
  2. Static initialization of class Foo (if not already completed)
  3. Static initialization of private static member instance with instance of Foo
  4. Entry toFoo.BarLength()

However, static initialization of a class is only ever triggered once per App Domain - and IIRC there's no blocking to ensure it's completed before any other static methods are called.

So, you could have this scenario:

  1. Thread Alpha: Call to Foo.BarLength()
  2. Thread Alpha: Static initialization of class Foo (if not already completed) starts
  3. Context Switch
  4. Thread Beta: Call to Foo.BarLength()
  5. Thread Beta: No Call to static initialization of class Foo because that's already underway
  6. Thread Beta: Entry to Foo.BarLength()
  7. Thread Beta: Access to null static member instance

There's no way the Contracts analyser can know that you'd never run the code in a multithreaded way, so it has to err on the side of caution.

Bevan
  • 43,618
  • 10
  • 81
  • 133
  • Right, but as you say (step 7), `instance` would be null, not `instance.bar`. `instance.bar` is only null before it's assigned in the constructor of the Foo instance, but the instance is only stored in the field strictly after the constructor has been completed. – dtb Apr 21 '10 at 01:25
  • Anyway, it's obviously a limitation of the static analyser. Now I'm looking for the best way to convince it that I'm right. Littering my code with `Assume` statements or with checks that can never occur feels just dirty. – dtb Apr 21 '10 at 01:29
  • Yes, the CLR does ensure that the static constructor completes before anything else on that class is referenced, unless you have two classes with static constructors that reference each other: http://msdn.microsoft.com/en-us/library/aa645612.aspx – EMP Apr 21 '10 at 01:44
  • Thanks for the link - it shows that in the single threaded case you have to set up a circular reference; however, it says nothing about the multi-threaded case that I documented above. Unfortunately, I've been unable to find my original reference - it was an odd edge case I read about some time ago. – Bevan Apr 21 '10 at 04:10
2

Update: It seems the problem is that invariants are not supported for static fields.

2nd Update: The method outlined below is currently the recommended solution.

A possible workaround is to create a property for instance that Ensures the invariants that you want to hold. (Of course, you need to Assume them for the Ensure to be proven.) Once you have done this, you can just use the property and all the invariants should be proven correctly.

Here's your example using this method:

class Foo
{
    private static readonly Foo instance = new Foo();
    private readonly string bar;

    public static Foo Instance
    // workaround for not being able to put invariants on static fields
    {
        get
        {
            Contract.Ensures(Contract.Result<Foo>() != null);
            Contract.Ensures(Contract.Result<Foo>().bar != null);

            Contract.Assume(instance.bar != null);
            return instance;
        }
    }

    public Foo()
    {
        Contract.Ensures(bar != null);
        bar = "Hello world!";
    }

    public static int BarLength()
    {
        Contract.Assert(Instance != null);
        Contract.Assert(Instance.bar != null);
        // both of these are proven ok

        return Instance.bar.Length;
    }
}
porges
  • 30,133
  • 4
  • 83
  • 114
  • Thanks for investigating this. Feel free to post it to the MSDN forum if you're interested in it. I've stopped using the static checker for now because a code review currently produces better results for me. – dtb May 06 '10 at 00:02
  • I've found a posting on the forum that states that invariants are not supported on static fields. I've updated my post with a workaround. – porges May 06 '10 at 03:18
  • Nice find. But `bar` is an instance field, not static!? Anyway, I've moved the check-mark to this answer because it's the best explanation so far. – dtb May 06 '10 at 12:11
  • I think that the problem is that `instance` is static, so any fields accessed via it don't work either. I've actually had a reply from one of the team and it seems that the solution I came up with is the (currently) recommended solution for static fields. – porges May 06 '10 at 12:46
0

If you mark the field 'bar' as readonly, that should satisfy the static analyzer that the field will never be set to anything else after the ctor executes.

anelson
  • 2,569
  • 1
  • 19
  • 30
  • Marking `bar` as read-only has no effect. For some reason, the analyser doesn't seem to realise that I'm assigning `bar` to a non-null value in the constructor. – dtb Apr 21 '10 at 01:32
-1

I agree with you. instance and bar are both private, so CodeContracts should be able to know instance.bar is never set to null.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539