How a garbage value is assigned in c/c++

Question

In C++/C if we don't initialize a variable, it will have some garbage values right? I would like to know from where these values are coming? Is it assigned by the compiler? Does this value have range? Is it the previous value present in the memory allocated to that variable? If yes can 5 or 500 be a garbage value?

This is not for any coding purpose, I just what to know it for learning.

>> " Is it the previous value present in the memory allocated to that variable". Yes, that's exactly correct. — anishsane, Sep 30 '13 at 12:42
That really depends on the type, context and **LANGUAGE** (no, C is not the same as C++). — bitmask, Sep 30 '13 at 12:43
Read [Can Anyone explain about the nature of output of the code?](http://stackoverflow.com/questions/17732322/can-anyone-explain-about-the-nature-of-output-of-the-code/17732426#17732426) — Grijesh Chauhan, Sep 30 '13 at 12:48
If you are compiling with optimizations on, the compiler may do arbitrary transformations based on the principle that the code that reads from uninitialized memory must necessarily be unreachable. In this case the “garbage” value may be a value that does not exist, such as the value that, multiplied by 2, produces an odd result. See the examples in http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined — Pascal Cuoq, Sep 30 '13 at 12:54
@GrijeshChauhan Uninitialized values are undefined, not random. After setting up the program and calling the main function, that value may happen to be what's left there by the hidden startup code. — Neil Kirk, Sep 30 '13 at 12:54
@GrijeshChauhan Sorry, I read the link name and thought you were asking the question.. — Neil Kirk, Sep 30 '13 at 13:10
@PascalCuoq: While we would like for that to be true, lately there's been a good deal of discussion to the effect that C seems to have defined away the undefined behavior of using indeterminate values when the range of the type does not admit trap representations. This upset the Itanic crowd because it conflicts with the hardware trapping for using uninitialized locals, and I believe there's a defect report somewhere for it to be changed back... Anyway, I don't remember all the details but apparently this issue is more complicated than most of us think. — R.. GitHub STOP HELPING ICE, Sep 30 '13 at 14:53
@R.. Do you mean http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm or do you mean another one to undo the change that resulted of DR338? PS: I love the phrase “an object of automatic storage duration that could have been declared with register storage class ” — Pascal Cuoq, Sep 30 '13 at 16:27

score 4 · Accepted Answer · answered Sep 30 '13 at 12:42

4

Any value can be garbage. It's whatever was left over in that spot of memory from the last operation that occurred there. It is unpredictable and never reliable, but it could be 5 or 500.

answered Sep 30 '13 at 12:42

Will Custode

4,576
3
26
51

score 1 · Answer 2 · answered Sep 30 '13 at 12:43

1

Assuming the compiler doesn't do anything special (which it might if you're doing a debug build), it'll be whatever happens to be in memory at the time.

It cannot be depended upon.

answered Sep 30 '13 at 12:43

xen-0

709
4
12

score 1 · Answer 3 · answered Sep 30 '13 at 12:44

1

It could be whatever value was in the memory position previously. It could be a magic value such as 0xCD, placed there by the debugger. It could be set to 0 for you by the compiler. It could be a value which isn't legal for the type (for example, not equal to any enum values).

answered Sep 30 '13 at 12:44

Neil Kirk

21,327
9
53
91

That why we say "default initialization is good practice". – Grijesh Chauhan Sep 30 '13 at 12:59
@GrijeshChauhan I don't understand. Who is we and why is it good practice? – Neil Kirk Sep 30 '13 at 13:09
Read [Initialize a variable](http://stackoverflow.com/questions/15201276/initialize-a-variable/15201353#15201353) – Grijesh Chauhan Sep 30 '13 at 13:13
@GrijeshChauhan I disagree. A default value may go undetected if it happens to work under current program logic or conditions. An uninitialised variable that changes will be more likely to go wrong and show there is a problem in the code. – Neil Kirk Sep 30 '13 at 13:18
That is only my view (just opinion)... – Grijesh Chauhan Sep 30 '13 at 13:19

score 0 · Answer 4 · answered Sep 30 '13 at 12:44

0

You get the value that is already there. So yes, this could very well be "5".

Note: if you run in DEBUG mode the environment will usually get zeroed memory, this is one way to get the weird behaviour we call "Heisenbugs" :-)

answered Sep 30 '13 at 12:44

Von Lion

748
4
22

score 0 · Answer 5 · edited May 23 '17 at 12:03

0

The garbage value is not assigned, rather the value is already there. When you allocate a variable you are reserving a piece of memory - until you overwrite it that memory will contain whatever "random" information was there before. Check this link which has the answer

Link

edited May 23 '17 at 12:03

Community

1
1

answered Sep 30 '13 at 12:45

Mogana

262
1
4
14

How a garbage value is assigned in c/c++

5 Answers5