-2

I am a little experienced in field of C# and its compiler set uninitialized variables's value to zero. I found this which is answer for my first question - why C++ doesn't.

But now - how C++ compiler 'chooses' random variable?

I think it's little more interesting/advanced than 'because it works like this'.

Community
  • 1
  • 1
Szkaplerny
  • 49
  • 3
  • 11
  • It's not setting it to a random value. It's just *not* overwriting whatever's there with 0. – Joe May 21 '16 at 17:30
  • Ok, but how it works? I create new variable, doesn't set any value, so it have just a memory address. So when I want to print it - from where compiler gets value? Why it is 223 and not 123467? – Szkaplerny May 21 '16 at 17:31
  • What variables are you talking about? Local variables? Fields in a class? Something else? – Theodoros Chatzigiannakis May 21 '16 at 17:32
  • 1
    The compilers never "choose" the value in an un-initialized variable. When you access the variable you get what is in memory. Blame the "random" value on the operating system or what ever task was using your memory before your program was executed. Residual values in memory. – Thomas Matthews May 21 '16 at 17:32
  • 1
    Every byte in RAM always holds a value. Without initialization, you get whatever values are left over from the last thing that used that RAM. – Wyzard May 21 '16 at 17:34
  • @ThomasMatthews so this value is just 'relic'? – Szkaplerny May 21 '16 at 17:35
  • Thank you guys, this is what I wanted to do! – Szkaplerny May 21 '16 at 17:35
  • 3
    This is better duplicate than marked one: http://stackoverflow.com/questions/1422729/how-does-an-uninitiliazed-variable-get-a-garbage-value – Destructor May 21 '16 at 17:37
  • @Destructor Agreed, did not see that one. – Baum mit Augen May 21 '16 at 17:47
  • "relic" data is a good way to think of it. Relic memory has security implications as well, you may find "Heartbleed Explanation" amusing: https://xkcd.com/1354/ – jgreve May 21 '16 at 18:42

2 Answers2

1

The values aren't "random", they're just whatever happened to be in memory already. That's what it means for a variable to be uninitialized.

Wyzard
  • 33,849
  • 3
  • 67
  • 87
  • 1
    *"they're just whatever happened to be in memory already."* That's just not true in general. – Baum mit Augen May 21 '16 at 17:36
  • @BaummitAugen: How can you say that? – Destructor May 21 '16 at 17:37
  • 1
    @Destructor MSVC explicitly overwrites them with debug values in debug builds, some platforms have *"invalid"* registers, ... The statement is simply not true. – Baum mit Augen May 21 '16 at 17:39
  • @BaummitAugen, what else would it be? If nothing sets a new value, the old value is still there. Note that the operating system will typically clear pages to zero before allocating them to a process, so it can't see data from a different process. But once a page has been allocated to a process, as it gets used and re-used, that process's own old data will be visible. – Wyzard May 21 '16 at 17:39
  • @BaummitAugen: you mean sometimes debug config. initializes automatic variables to 0 in some implementation. right? – Destructor May 21 '16 at 17:40
  • 1
    @Destructor I think MSVC uses 0xCCC... or 0xCDCD... or something like this to indicate "not initialized". But sure, setting it to 0 would be just as legal. – Baum mit Augen May 21 '16 at 17:41
  • Setting those values is initialization. They're meant to let you know that the memory *would* have been uninitialized in a non-debug build, but they're not the sort of "random values" in uninitialized variables that the question was asking about. – Wyzard May 21 '16 at 17:57
  • 1
    a) Writing some pattern to memory is not the same as initializing a variable. For instance, an implementation is free to trap on such a pattern interpreted as `double` (can't happen on properly initialized `double`s), pointers would still be invalid, ... b) This still does not address implementations that do not silently ignore reads on uninitialized memory. – Baum mit Augen May 21 '16 at 18:02
0

This is implementation dependant, but typically the compiler doesn't choose any value for the variable. Instead the compiler allocates space on the stack where the variable will be stored - but it doesn't put any value there. So if you read the uninitialized variable, you will probably get whatever happened to be on the stack beforehand.