Where are the garbage value stored, and for what purpose?
-
7Garbage values aren't "stored" and serve no "purpose". They are simply whatever happens to be in the memory space occupied by an uninitialized variable. – Cogwheel Jul 14 '10 at 16:07
-
2too fast too fast. It's a question. It can (could/must) be explained better. But it is a question. Maybe a duplicate, but it is a question. My ongoing answer was: >> – ShinTakezou Jul 14 '10 at 16:10
-
1The garbage value is not stored purposely. Simply, memory and registers hold values. If noone sets them to something meaningful for whoever is interested in (like the caller of a function), it happens that the "caller" gets a "garbage" value, i.e. accesses an area of memory or a register that noone has set to a meaningful value, so it can be whatever according to who owned that memory before, or the last computation done, or any other "unpredictable" fact. If you mean something different, specify better your question. – ShinTakezou Jul 14 '10 at 16:11
-
thanx for reopening my post , i really wanted to get some answers so that i could give a brief explanation in my class...(sad some ppl closed it) – subanki Jul 14 '10 at 17:11
-
You question is pretty well answered in the comments posted here. If you do not initialize a variable, it will contain whatever random bits are in that particular memory location. Why does C (or more specifically, the C compiler) allow this? Probably for simplicity and performance reasons. You, the programmer, are responsible for initializing your variables so that your code is safe. – Robert Harvey Jul 14 '10 at 17:14
5 Answers
C chooses to not initialize variables to some automatic value for efficiency reasons. In order to initialize this data, instructions must be added. Here's an example:
int main(int argc, const char *argv[])
{
int x;
return x;
}
generates:
pushl %ebp
movl %esp, %ebp
subl $16, %esp
movl -4(%ebp), %eax
leave
ret
While this code:
int main(int argc, const char *argv[])
{
int x=1;
return x;
}
generates:
pushl %ebp
movl %esp, %ebp
subl $16, %esp
movl $1, -4(%ebp)
movl -4(%ebp), %eax
leave
ret
As you can see, a full extra instruction is used to move 1 into x. This used to matter, and still does on embedded systems.

- 598
- 5
- 19
-
I'm not sure what is meant by: "this used to matter, and still does on embedded systems". – Michael Burr Jul 14 '10 at 17:35
-
4@Michael Burr: I interpreted it as "unless you're working on an embedded system, you shouldn't worry about the performance impact of the extra instruction." – Cogwheel Jul 14 '10 at 18:12
-
3It does still matter if your auto variable is a large array and your function happens to not do a lot in that call. – ninjalj Jul 14 '10 at 18:13
-
2@Cogwheel: That was what it was intended to get across. You know the rules: make it work, make it right, make it fast... In THAT order. – Rannick Jul 14 '10 at 19:52
-
@ninjalj: given that my commodity laptop has a processor capable of doing 120 million instructions per second, you would have to be dealing with a VERY large array. Obviously you can make the case occur, but in reality, variable initialization does not take enough overhead to be given a second thought outside of the embedded world. – Rannick Jul 14 '10 at 19:55
-
2@Rannick: or you could be calling that function thousands of times a second. It happened in a project I worked on. Some logging function was initializing a buffer, and then deciding that logging was disabled for anything with less priority than ERROR and returning. – ninjalj Jul 14 '10 at 21:38
-
@ninjalj: Ahh, i gotcha... That does sound like some scary code as well. I accept your large array exception, but i still say most variables can stand to be better served by being initialized to their default value, or an error value. I bet you run into the same issues at your place's definition of ANSI compliant. There's nothing wrong with defining variables on a per-block basis. It further limits their scope, as well. Initialize said buffer as the first thing in your if statement, or maybe a new function is in order? – Rannick Jul 14 '10 at 23:36
-
Not just embedded. If that extra instruction were part of a database query engine, then it could cost that database vendor's customers lots of $$$ in datacenter energy bills. If it were part of a graphics engine then it might contribute to a diminished experience for the users of some game. – Oktalist Sep 21 '14 at 17:44
Garbage values are not really stored anywhere. In fact, garbage values do not really exist, as far as the abstract language is concerned.
You see, in order to generate the most efficient code it is not sufficient for the compiler to operate in terms of lifetimes of objects (variables). In order to generate the most efficient code, the compiler must operate at much finer level: it must "think" in terms of lifetimes of values. This is absolutely necessary in order to perform efficient scheduling of the CPU registers, for one example.
The abstract language has no such concept as "lifetime of value". However, the language authors recognize the importance of that concept to the optimizing compilers. In order to give the compilers enough freedom to perform efficient optimizations, the language is intentionally specified so that it doesn't interfere with important optimizations. This is where the "garbage values" come into picture. The language does not state that garbage values are stored anywhere, the language does not guarantee that the garbage values are stable (i.e. repeated attempts to read the same uninitialized variable might easily result in different "garbage values"). This is done specifically to allow optimizing compilers to implement the vital concept of "lifetime of value" and thus perform more efficient variable manipulation than would be dictated by the language concept of "object lifetime".

- 312,472
- 42
- 525
- 765
IIRC, Thompson or Richie did an interview some years ago where they said the language definition purposely left things vague in some places so the implementers on specific platforms had leeway to do things that made sense (cycles, memory, etc) on that platform. Sorry I don't have a reference to link to.

- 3,579
- 28
- 31
-
It's visible everywhere in the language, e.g. the undefined size of arithmetic types etc. – Peter - Reinstate Monica Aug 25 '14 at 08:26
Why does the C standard leave use of indeterminate variables undefined?
It does not :-) :
for local variables, it says undefined behavior, which means that anything (e.g. segfault, erasing your hard disk) is legal: (Why) is using an uninitialized variable undefined behavior?
for global variables, it zeros them: What happens to a declared, uninitialized variable in C? Does it have a value?

- 347,512
- 102
- 1,199
- 985
C was designed to be a relatively low-level language so that it could be used for writing, well, low-level stuff like operating systems. (in fact, it was designed so that UNIX could be written in C) You can simply think of it as assembly code with readable syntax and higher-level constructs. For this reason, C (minus optimizations) does exactly what you ask it to do, nothing more, nothing less.
When you write int x;
, the compiler simply allocates memory for the integer. You never asked it to store anything there, so whatever was in that location when your program started stays as such. Most often, it turns out that the pre-existing value is "garbage".
Sometimes, an external program (for eg. a device driver) may write into some of your variables, so it is unnecessary to add another instruction to initialize such variables.

- 69,683
- 7
- 133
- 150
-
A swap function is a good example where initializing the temp variable would be completely pointless (and costly relative to the overall function runtime). Most functions will be longer so that the runtime cost of an automatic initialization would be relatively smaller but then, as @ninjalj pointed out, there are cases with large data where it would really hurt if you can't turn it off. – Peter - Reinstate Monica Aug 25 '14 at 08:31