views:

397

answers:

7

Right,

Another question from me:

I have the following piece of code:

class Foo
{

    public Foo()
    {
        Bar bar;
        if (null == bar)
        {

        }
    }
}

class Bar { }

Code gurus will already see that this gives an error. Bar might not be initialized before the if statement.

So now I'm wondering: what IS the vlaue of bar, shouldn't it be null? Aren't they set to null? (nullpointer?)

+22  A: 

No, local variables don't have a default value1. They have to be definitely assigned before you read them. This reduces the chance of you using a variable you think you've given a sensible value to, when actually it's got some default value. This can't be done for instance or static variables because you don't know in what order methods will be called.

See section 5.3 of the C# 3.0 spec for more details of definite assignment.

Note that this has nothing to do with this being a reference type variable. This will fail to compile in the same way:

int i;
if (i == 0) // Nope, i isn't definitely assigned
{
}

1 As far as the language is concerned, anyway... clearly the storage location in memory has something in it, but it's irrelevant and implementation-specific. There is one way you can find out what that value is, by creating a method with an out parameter but then using IL to look at the value of that parameter within the method, without having given it another value. The CLR doesn't mind that at all. You can then call that method passing in a not-definitely-assigned variable, and lo and behold you can detect the value - which is likely to be the "all zeroes" value basically.

I suspect that the CLI specification does enforce local variables having a default value - but I'd have to check. Unless you're doing evil things like the above, it shouldn't matter to you in C#.

Jon Skeet
It's controlled by the *localsinit* flag on the method's metadata. See Partition III section 3.47 "localloc" for details. I seem to recall that the CLR always does initialize stack memory to zero regardless. Or perhaps it always does so when a debugger is attached? I'm not sure. In any event, locals observed in their uninitialized state through sneaky means pretty much always seem to have their default values.
Eric Lippert
+2  A: 

Local variables do not get assigned a default value. You have to initialize them before you use them. You can explicityly initialize to null though:

public Foo()
{
    Bar bar = null;
    if (null == bar)
    {

    }
}
Justin Niessner
+7  A: 

Fields (variables on classes / structs) are initialized to null/zero/etc. Local variables... well - since (by "definite assignment") you can't access them without assigning there is no sensible way of answering; simply, it isn't defined since it is impossible. I believe they happen to be null/zero/etc (provable by hacking some out code via dynamic IL generation), but that is an implementation detail.


For info, here's some crafy code that shows the value of a formally uninitialised variable:

using System;
using System.Reflection.Emit;
static class Program
{
    delegate void Evil<T>(out T value);
    static void Main()
    {
        MakeTheStackFilthy();
        Test();
    }
    static void Test()
    {
        int i;
        DynamicMethod mthd = new DynamicMethod("Evil", null, new Type[] { typeof(int).MakeByRefType()});
        mthd.GetILGenerator().Emit(OpCodes.Ret); // just return; no assignments
        Evil<int> evil = (Evil<int>)mthd.CreateDelegate(typeof(Evil<int>));
        evil(out i);
        Console.WriteLine(i);
    }
    static void MakeTheStackFilthy()
    {
        DateTime foo = new DateTime();
        Bar(ref foo);
        Console.WriteLine(foo);
    }
    static void Bar(ref DateTime foo)
    {
        foo = foo.AddDays(1);
    }
}

The IL just does a "ret" - it never assigns anything.

Marc Gravell
I hadn't spotted that you'd found the way of determining the value using an out parameter too - I'd just added that to my answer. Evil, nasty stuff.
Jon Skeet
I don't know if this is a stupid question, but why is the behaviour different for fields compared to local variables? Is it due to scope, i.e. a local variable is only valid within a function? Or is there another reason?
Matt Warren
@Jon - you don't even need that; if you have a delegate-type that is "out YourType value", just create a `DynamicMethod` with IL="ret", call `CreateDelegate` and invoke the delegate "out myVariable". Then inspect the variable. No need to do the hard work in the dynamic method.
Marc Gravell
@Matt: That is not at all a bad question. I discuss some of those issues here: http://blogs.msdn.com/ericlippert/archive/2009/10/12/absence-of-evidence-is-not-evidence-of-absence.aspx but I don't actually answer your specific question. Basically: (1) you are much more likely to get "false positive" errors when showing that a field is possible read before it is written, (2) the compiler does give warnings for fields which are never written or never read, (3) unlike locals, fields have an entire method -- the constructor -- specifically for initializing them.
Eric Lippert
@Jon - added the IL example, btw
Marc Gravell
@Eric thanks for the extra info, that makes a lot more sense now.
Matt Warren
+1  A: 

Local variables are not assigned a default value, not even a null.

Bryan Denny
+1  A: 

The value of bar is undefined. There's space allocated for it on the stack, but the space isn't initialised to any value so it contains anything that happened to be there before.

(The local variable might however be optimised to use a register instead of stack space, but it's still undefined.)

The compiler won't let you use the undefined value, it has to be able to determine that the variable is initialised before you can use it.

As a comparison, VB does initialise local variables. While this can be practical sometimes, it can also mean that you unintenionally use a variable before you have given it a meaningful value, and the compiler can't determine if it's what you indended to do or not.

Guffa
A: 

It doesn't matter because no such code should be compilable by any compiler that implements C#.

If there was a default value, then it would be compilable. But there is none for local variables.

Brian R. Bondy
A: 

Besides "correctness", local variable initialization is also related to the CLR's verification process.
For more details, see my answer to this similar question: http://stackoverflow.com/questions/753438/why-must-local-variables-have-initial-values/3383168#3383168

Liran