Uninitialized variable in C

Question

I'm a little bit confused. As far as I know, if you declare an int in C, without initializing it, for e.g: int x;

so its value is indeterminate. So if we try to use it or should have undefined behavior.

So if i'm running the following code in VS2010 It crash the program.

int main(){
    int a;
    printf("%d\n",a);
    return 0;
}

Now lets take a look at the next code, which does not provide any warning and does not crash (why?)

void foo(int *var_handle){
    // do nothing
}

int main(){
    int a;
    foo(&a);
    printf("%d\n",a); // works, prints some big value
    return 0;
}

Can you explain the behavior of this? we only added a call to a function which does nothing at all, but now program wont crash.

Answer 1

Reading the value of an uninitialized variable leads to undefined behavior. And undefined behavior means that it can crash. It doesn't mean it will or it is obliged to crash.

An uninitialized variable has unspecified value - it's just unknown what its value is. So in practice, with any sane implementation, this kind of code will presumably never crash. There's a valid memory address backing the variable, it has some garbage content, printf() reads it without problem, interprets it as an integer and prints it, that's all.

Answer 2

Using an uninitialized value does not directly cause undefined behavior.

Per C 2011 (n1570 draft) 6.7.9 10, an uninitialized object with automatic storage duration has indeterminate value. Per 3.19.2 1, an indeterminate value is either an unspecified value or a trap representation. Similar text appears in C 1999.

If the object has a trap representation, then undefined behavior may occur. However, if the object has an unspecified value, then program must behave has if the object has some determinate value; it is merely not specified which value the object has. The program is not permitted to crash merely because the value is unspecified.

It is surprising that you report the simple program shown crashes in Visual Studio 2010, because I do not expect that the int type has any trap representations in Visual Studio 2010. It may be that some source file other than what you expected was compiled and crashed or that you have enabled special debugging features in Visual Studio 2010 that attempt to track uninitialized objects (but fail in the second case where you use foo).

I suggest you repeat the test from scratch, pasting the code you displayed in this question into a new file and compiling that new file with default options.

Of course, Visual Studio 2010 does not conform to the C standard, not even the old 1999 standard, so it is not bound to obey the above clauses. In effect, everything about Visual Studio 2010 is undefined behavior with regard to the C standard.

Answer 3

It's undefined behaviour, meaning that anything could happen. Literally anything. The behavior is just not defined.

Answer 4

You could try this. I don't know if it is strictly undefined behaviour or not, but I can't think of a way for a compiler to actually behave in undefined manner and still be compliant with C standard, at least if foo is in different compilation unit (~source file), because then compiler does not know it would be allowed to produce undefined behaviour ;).

void foo(int *var_handle){
    // do something to var_handle, or maybe nothing, who knows
}

int main(){
    int a[1];
    foo(a);
    printf("%d\n", a[0]);
    return 0;
}

Edit: Further thoughts:

I'm fairly certain it's ok to use a function to initialize uninitialized local variable, by giving non-const pointer to the local variable to the function. So, merely getting address of a local variable makes it defined variable with undefined value, as far as compiler is concerned. Compiler can not know if the function actually sets the value or not (function might be in a library).

But this just explains why it avoids the crash. It could still be, that if function is allowed to be inlined, and did nothing, optimizer would be allowed to remove the call, and then also remove taking address of uninitialized local variable, thus leaving it still in "undefined behaviour" state. You could test this for your compiler by turning up optimizations and verifying from assembly output, that call to foo gets inlined (producing no code), and see if printf crashes then.

Answer 5

There is no guarantee that using an uninitialised variable will cause your program to crash - it depends what junk data happens to be in the memory location allocated for the variable.

Answer 6

On an x86 or x86-64, premature optimization prevent the load of value from the variable:

int b;
b -= b; // b = eax - b, not 0

int c;
c ^= c; // c = eax - c, not 0

// eax, whatever happens to be the value in the eax register.
// rax for 64-bit, eax for 32-bit and less using bit mask,
// ax for int is 16 bit compilers.

Undefined behavior could mean anything. For uninitialized variable, it would behave as its type, but the value is unknown and cannot be verified. An uninitialized variable automatically take the value in the "accumulator" (integral: eax, rax; floating point/simd: xmm0, ymm0, zmm0, etc.) and not load it from random access memory (or cache) unless it is volatile. You can initialize the variable by assigning a value to it, given the non-lvalue does not use an uninitialized variable.