Why are local variables not set to zero?

Question

Since global and static variables are initialized to 0 by default, why are local variables not initialized to 0 by default as well?

see http://stackoverflow.com/questions/3553559/how-are-local-and-global-variables-initialized-by-default and http://stackoverflow.com/questions/2218254/variable-initialization-in-c — Marius Bancila, Feb 21 '14 at 10:51
@JoachimPileborg The definition in C says they are initialized as if initialized with the value `0`, converted to the correct type. C++ uses the same definition for the basic types (and recurses for the others). This doesn't mean all 0 bits, of course, since the type conversion could change the bit pattern, but it is one interpretation of "initialized to 0". — James Kanze, Feb 21 '14 at 11:03

score 14 · Accepted Answer · answered Feb 21 '14 at 10:53

14

Because such zero-initializations take execution time. It would make your program significantly slower. Each time you call a function, the program would have to execute pointless overhead code, which sets the variables to zero.

Static variables persist for the whole lifetime of the program, so there you can afford the luxuary to zero-initialize them, because they are only initialized once. While locals are initialized in runtime.

It is not uncommon in realtime systems to enable a compiler option which stops the zero initialization of static storage objects as well. Such an option makes the program non-standard, but also makes it start up faster.

answered Feb 21 '14 at 10:53

Lundin

195,001
40
254
396

I think static variables of build-in types don't have do be initialized at runtime at all because they are already initialized in the binary data section. – TNA Feb 21 '14 at 11:00
@TNA On most systems (including Unix and Windows), they are initialized by the OS when the program is loaded. They will be initialized to zero, whether the compiler wants it or not. – James Kanze Feb 21 '14 at 11:05
@JamesKanze I thought static variables are just offsets into data section, which is loaded when the program is loaded. How can it be that a *symbol* doesn't point to anywhere until loaded? – user3125367 Feb 21 '14 at 11:29
@TNA The manner of how they get initialized is implementation-defined. On RAM-based desktop systems, they will indeed get loaded at start-up by the OS. On systems with true NVM, there has to be a copy-down code executed in runtime, before main() is called. – Lundin Feb 21 '14 at 11:47
@user3125367 There aren't any symbols in executable code. Just addresses. The compiler and the linker together generate the addresses, and insert them in the code. The OS (the loader) ensures that there is memory at the addresses. – James Kanze Feb 21 '14 at 13:35
@JamesKanze When the compiler wants, it sets value in [the future] data section. And that section is then loaded into 'addresses'. That is the original statement of TNA. Maybe data sections are not well-covered by standards, but on Unix and Windows they are *loaded* from executable image (as-is, at least) and never zeroed out by OS, unless .bss section, which is just optimization of executable size. Please correct me if I'm wrong. – user3125367 Feb 21 '14 at 18:33
@JamesKanze "There aren't any symbols in executable code. Just addresses." Not always true, but it was not about that. Linked executable contains load-ready data sections with original offsets that were original symbols some time ago. – user3125367 Feb 21 '14 at 18:36
@user3125367 On Unix systems (and on Windows as well, I think), the `.data` segment is simply an image on disk, which is loaded into memory. The `.bss` segment doesn't have an image on disk; only information regarding size, etc. The OS reserves this memory, and initializes it to zero. (For security reasons, the OS always initializes the memory it allocates to a process.) And while the executable may contain symbols for debugging, or for dynamic linking, these are not used when loading the initial process image (unless this triggers loading of some dynamic objects as well). – James Kanze Feb 22 '14 at 12:04

Andreas Grapentin · Answer 2 · 2014-02-21T10:57:58.700

9

This is because global and static variables live in different memory regions than local variables.

uninitialized static and global variables live in the .bss segment, which is a memory region that is guaranteed to be initialized to zero on program startup, before the program enters `main'
explicitly initialized static and global variables are part of the actual application file, their value is determined at compile-time and loaded into memory together with the application
local variables are dynamically generated at runtime, by growing the stack. If your stack grows over a memory region that holds garbage, then your uninitialized local variables will contain garbage (garbage in, garbage out).

edited Feb 21 '14 at 10:57

answered Feb 21 '14 at 10:52

Andreas Grapentin

5,499
4
39
57

There is no allocation difference between "static" and "globals", they both have _static storage duration_ and are always allocated either in `.bss` or in `.data`, depending on whether they were explicitly initialized or not. So no, static variables are not necessarily allocated in `.bss`. – Lundin Feb 21 '14 at 10:55
This is, of course, the usual implementation on Unix based machines. There's no requirement for it to be so. – James Kanze Feb 21 '14 at 11:08
@JamesKanze No guarantees but very common on all kinds of applications, from tiny embedded bare-bone ones to PCs. – Lundin Feb 21 '14 at 11:45
@Lundin It certainly isn't common on machines which don't have a disk. – James Kanze Feb 21 '14 at 13:36
@JamesKanze It is incredibly common. Every bare-bone embedded system I've worked on for the past 5 years or so have this setup. ARM, Power PC, all Freescale MCUs... Basically every tool chain using elf/dwarf linkers. – Lundin Feb 21 '14 at 13:49
1

@AndreasGrapentin You said **"local variables are dynamically generated at runtime"**. So is the above statement true only for *uninitialized* local variable? And if we explicitly *initialize* a local variable say like `int p = 0;` then will that local variable be not dynamically generated at runtime ? Second, can you also cite the source supporting this(your) claim. – Jan 03 '22 at 12:45
@AanchalSharma you do realize this answer is now close to 8 years old? this might not be the right place to ask follow-up questions. However, in your example, an /initialized/ local variable will still be dynamically generated on the stack, but the compiler will add code to initialize it with the specified value. See also Lundin's excellent answer above mine. :) – Andreas Grapentin Jan 09 '22 at 09:56

unwind · Answer 3 · 2014-02-21T10:58:15.090

6

Because that would take time, and it's not always the case that you need them to be zero.

The allocation of local variables (typically on the CPU's hardware stack) is very fast, much less than one instruction per variable and basically independent of the size of the variables.

So any initialization code (which generally would not be independent of the size of the variables) would add a relatively massive amount of overhead, compared to the allocation, and since you cannot be sure that the initialization is needed, it would be very disruptive when optimizing for performance.

Global/static variables are different, they generally live in a segment of the program's binary that is set to 0 by the program loader anyway, so you get that "for free".

edited Feb 21 '14 at 10:58

answered Feb 21 '14 at 10:51

unwind

391,730
64
469
606

The example is not very good, for two reasons. First, any compiler worth its salt would detect that suppressing the original initialization would not change the observable behavior of the code, and do so; and second because if the actual initialization is expensive, the zero initialization would not be noticeable compared to it. – James Kanze Feb 21 '14 at 10:55
@JamesKanze Fine, I removed the example. Thanks. – unwind Feb 21 '14 at 10:58
@JamesKanze But suppose that the loop condition was not a compile-time constant, but a runtime one. Then the compiler couldn't really make that optimization. – Lundin Feb 21 '14 at 10:58
@Lundin It depends. If you never access the element, the compiler can see this, and not initialize. The real case which would cause the compiler problems is if you did something like `int array[10000]; initializeArray( array, 10000 );`, where `initializeArray` is in a different translation unit. – James Kanze Feb 21 '14 at 11:07

Balu · Answer 4 · 2014-02-21T11:09:25.403

0

Global and static variables are stored at Data Segment [Data in the uninitialised data segment is initialized by the kernel to arithmetic 0 before the program starts executing], while local variables are stored at call stack.

edited Feb 21 '14 at 11:09

answered Feb 21 '14 at 10:51

Balu

2,247
1
18
23

score 0 · Answer 5 · answered Feb 21 '14 at 11:00

Mainly historical. Back when C was being defined, the zero initialization of static variables was handled automatically by the OS, and would occur anyway, where as the zero initialization of local variables would require runtime. The first is still true today on a lot of systmes (including all Unix and Windows). The second is far less an issue, however; most compilers would detect a superfluous initialization in most cases, and skip it, and in the cases where the compiler couldn't do so, the rest of the code would be complicated enough that the time required for the initialization wouldn't be measurable. You can still construct special cases where this wouldn't be the case, but they're certainly very rare. However, the original C was specified like this, and none of the committees have reviewed the issue since.

score 0 · Answer 6 · answered Feb 21 '14 at 11:24

The global or static variables that are initialized by you explicitly will be stored in the .data segment (initialized data) and the uninitialized global or static variables are stored in the .bss (uninitialized data).

This .bss is not stored in the compiled .obj files because there is no data available for these variables (remember you have not initialized them with any certain data).

Now, when the OS loads an exe, it just looks at the size of the .bss segment, allocates that much memory, and zero-initializes it for you (exec). That's why it is necessary to initialize .bss segment to zero.

The local variables are not initialized because there is no such need to initialize them. They are stored at the stack level, so loading an exe will automatically load that amount of memory needed by the local variables. So, why to do extra initialization of local variables and make our program slower.

score 0 · Answer 7 · answered Feb 21 '14 at 11:32

Suppose you need to call a function 100 times and if there is a local variable and suppose if it were to initialise to 0 every time...oops there will be extra overhead and wastage of time. on the other hand global variables are initialised only once.so we can afford its default initialising to 0.

Why are local variables not set to zero?

7 Answers7

Linked