tags:

views:

217

answers:

3

In C/C++ why globals and static variables are initialized to default values.. why not leave it with just garbage values ? Any special reasons for this ?

+13  A: 
DigitalRoss
I guess the asker wants to know why `static int x;` always make `x` initialized to zero while `int x;` leaves `x` being garbage.
KennyTM
Hmm, you might be right, I've revised the answer to address that.
DigitalRoss
Actually the real reason is that the original C standard was to codify existing practice rather than introduce new stuff. And pre-ANSI/ISO C did it for efficiency.
paxdiablo
"The very first stack frame does receive zero values". I'm not even sure what that means. Where does that idea come from?
Michael Burr
@michael Burr: do you really think that pages allocated for the stack are not zeroed? Really? Of course they are. The stack does start as demand paged zero-fill pages. Because any given address is used multiple times by repeated instances of functions at the same stack level, the values appear random. But they are not, and they will be generally the same "garbage" values in repeated runs if the arguments and environment are not changed. This is complicated somewhat by modern OS security concerns that change addresses of load points to fight stack-smashing attacks, but that's another story.
DigitalRoss
DigitalRoss: The "very first stack frame" is often not used by code that you've written, but by the program prologue and initialisation routines for the standard library. And not every OS zeroes stack (or heap!) memory before program start - for example MS-DOS does (did?) not.
caf
@caf, of course. But from the kernel's point of view and from a security point of view, it's still your program, and those pages really did start as zeroed pages. Sure, by the time you get to main(), maybe it doesn't look that way, but new stack levels you reach will be zeroed the first time you reach them and cross into a new page that the kernel must allocate.
DigitalRoss
@paxdiablo, I guess I agree in part. Certainly C89's (somewhat ignored) mandate was to "codify existing practice", but in this case the practice does seem to make perfect sense...
DigitalRoss
@DigitalRoss: even if you're on a platform that provides zero-filled pages for the stack (which is very common, but not necessarily universal), that doesn't mean that the first time a function is called that the locals will end up in zero-filled memory. For example, when `main()` is called, there's no telling what the runtime has done to the stack before that point. Not to mention that a local variable might not even end up on the stack (it might exist solely in a register for example). That a stack might be zero-initialized is meaningless information as far as C/C++ locals are concerned.
Michael Burr
@Michael Burr: I never said anything about "the first time a function is called", instead I was discussing the first use of new levels on the stack. I agree that this information isn't much use when programming, as you must always assume that locals can have any bit pattern. My point was to explain how things worked, and I believe everything I said was accurate...
DigitalRoss
+7  A: 

Because with the proper cooperation of the OS, 0 initializing statics and globals can be implemented with no runtime overhead.

R Samuel Klatchko
+2  A: 

Think about it, in the static realm you can't tell always for sure something is indeed initialized, or that main has started. There's also a static init and a dynamic init phase, the static one first right after the dynamic one where order matters.

If you didn't have zeroing out of statics then you would be completely unable to tell in this phase for sure if anything was initialized AT ALL and in short the C++ world would fly apart and basic things like singletons (or any sort of dynamic static init) would simple cease to work.

The answer with the bulletpoints is enthusiastic but a bit silly. Those could all apply to nonstatic allocation but that isn't done (well, sometimes but not usually).

Charles Eli Cheese