Why local variable is initialized to zero

Question

According to my knowledge, local variables are uninitialized i.e, it contains garbage value. But following program is giving 0 (zero) as output.

main()
{
    int i;
    printf("%d\n",i);
}

When i run above program it is giving always 0. I know that 0 is also can be a garbage value but every time i am getting zero as output. Can anybody know reason for it?

It is basically accidental...and misleads people. Don't rely on it; on other machine types, it won't necessarily be zero. — Jonathan Leffler, Jul 15 '13 at 06:04
Is 0 not allowed to be a garbage value? `gcc` X on distro Y version Z may set that to 0, but no other environment is guaranteed to. — Corbin, Jul 15 '13 at 06:04
The wiki article is great http://en.wikipedia.org/wiki/Uninitialized_variable — AurA, Jul 15 '13 at 06:06
@Jonathan: The guy knows that it is undefined, not reliable and what have you... He is asking why is he getting a zero consistently or so it seems. — Tarik, Jul 15 '13 at 14:22
@Tarik: it is likely something to do with the way stack is initialized on that system, and the way the startup code (which runs before `main()` runs) works, not trampling over that zeroed stack. Or it may be that the startup code happens to leave a zero at the space that becomes `i` reliably and consistently (a loop counts down to zero, perhaps). It would take careful analysis of the code that runs before `main()` is called to know what's really going on there — and it isn't worth it because it can't be relied on. A new release of the o/s or compiler or library might change the behaviour. — Jonathan Leffler, Jul 15 '13 at 14:32
@Jonathan: Yep, it might be due to various system factors that "would take careful analysis..." to figure out. As of its worthiness, that's another story which does not seem to be the object of this question. In brief so far, we got what was already known: behavior not defined, source of bug, woooh, should not be done...blah blah blah...and...well we do not really know. Let's just admit it, we do not really know exactly why it happens this way on his system and maybe we rightfully do not believe it is worth spending our time to find out. Let's just have the honesty to say "I do not know". — Tarik, Jul 15 '13 at 14:41

Yu Hao · Answer 1 · 2013-07-15T06:12:44.947

5

Garbage value means whatever happened to be in that memory location. In your case, the value happened to be zero. It may not be the case in another machine.

Note that some compiler will fill uninitialized variable with some magic value for the purpose of debugging (like 0xA5A5), but it's usually not zero, either.

edited Jul 15 '13 at 06:12

answered Jul 15 '13 at 06:06

Yu Hao

119,891
44
235
294

score 3 · Accepted Answer · answered Jul 15 '13 at 06:06

When i run above program it is giving always 0. I know that 0 is also can be a garbage value but every time i am getting zero as output.

Whatever happened to cause a 0 to be written into the location where i is now probably happens every time the program runs. Computers are nice and reliable like that. "garbage" doesn't necessarily mean "random" or "always changing," it just means "not meaningful in any context that I care about."

score 2 · Answer 3 · answered Jul 15 '13 at 06:14

2

I think it is just an accident. local variable is indeed uninitialized, but the memory your compiler allocate for the (int i) variable is not used previously by your current process, so there is no garbage value.

answered Jul 15 '13 at 06:14

lulyon

6,707
7
32
49

What about the compiler generating a data area initialized to zero? – Tarik Jul 15 '13 at 07:55
@Tarik I think it is possible. – lulyon Jul 15 '13 at 07:56

score 1 · Answer 4 · answered Jul 15 '13 at 06:07

1

Luck! The behaviour is undefined, and so the answer depends on your compiler and system. This time, you happened to get lucky that the first four bytes in that area of memory were zero. But there is no guarantee that it will always do so, from one system to the next or even from one invocation to the next.

answered Jul 15 '13 at 06:07

gavinb

19,278
3
45
60

What about the compiler generating a data area initialized to zero? – Tarik Jul 15 '13 at 06:16
1

Some compilers have an option to initialise variables to sentinel values in debug builds (eg. 0xcc with MSVC), but for normal release builds, I'm not aware of one. This has been discussed a number of times, including http://stackoverflow.com/questions/14049777/why-global-variables-are-always-initialized-to-0-but-not-local-variables and http://stackoverflow.com/questions/2091499/why-global-and-static-variables-are-initialized-to-their-default-values – gavinb Jul 15 '13 at 12:40

score 1 · Answer 5 · answered Jul 15 '13 at 06:08

A possible reason for printing always 0 is that main is started in a well defined state; more exactly, an ELF program is starting with a well defined stack (defined by the ELF specification) and registers, so its _start function (from crt*.o) which is the ELF executable starting point gets a well defined stack, and calls main .

Try making your function some other name, and call it in various states (e.g. call it several times from main in more complex ways). Try also running your program with different program arguments and environments. You'll probably observe different values for i

Your program exhibits some undefined behavior (and with all warnings enabled gcc -Wall is warning you).

score 0 · Answer 6 · answered Jul 15 '13 at 09:02

As far as I know, uninitialized variables in Linux are first "allocated" in the Zero Page - a special page that contains only zeros.
Then, at the first write to the unitialized variable, the variable is moved from the zero page to another page that is not write-protected.

Why local variable is initialized to zero

6 Answers6