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
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.
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.
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.
It's undefined behaviour, meaning that anything could happen. Literally anything. The behavior is just not defined.
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.