by Spike » Wed Mar 23, 2011 5:10 pm
variables can be in one of 3 locations.
data.
bss.
stack.
data is always initialised.
bss is virtually always initialised, but there may be some (broken) systems that don't
stack is never initialised.
a global(or static local) which is initialised will be stored in the data section, regardless of the actual value which is assigned to it.
a global(or static local) which is NOT initialised will be stored in the bss section. It will be initialsed to 0, NULL, nothing, just all its bits will be 0 regardless of its type.
a local(non static) is stored on the stack. If you do not assign to it, its initial value will be UNKNOWN! If its a pointer, it'll probably crash you, if its an integer, you'll still get undefined results.
information stored in the data section will increase the size of your exe.
Information stored in the bss section will not increase the size of your exe (other than the instructions required to access it).
Note that by 'unknown', I mean that it'll have whatever value was previously stored there, if you read it.
In certain situations, this value can be fairly reliably guessed, and so you might not instantly realise that there's a bug there, indeed you may never notice a problem. However, such bugs are a pain when you change optimisations or compiler, as the value may no longer be so reliable.
Also note that certain compilers (notably gcc) have randomized seeding of register choices. This means that your 'safe' values can change from build to build, so rebuilding it can result in different apparent bugs being exhibited.
Valgrind is a good way to check if your program is failing to initialise any variables which are a problem.
To sum up: don't bother initialising globals, especially if they're large arrays/structs. But _always_ intialise locals.
.