Variable Initialization

[Baker]

Does MSVC6, gcc and more recent Microsoft Visual Studio initialize variables?

For example:

int i; // <--- is that going to be 0 or uninitialized?
char *mystring; // <---- is that going to be null?
char mystring[40]; // <--- is that going to be 0 filled?

I have conflicting sources of information and am not quite sure what the answer is.

If they are initialized, it is a waste of time to do this ...

char *mystring = NULL;

If I had to guess ... I'd say MSVC does initialize variables and that gcc might not or may require a compiler option.

[Spike]

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.

[Baker]

That was my understanding for the most part (storage class determines intialization) but I was a bit confounded by some of the odd things here in there in various engine codes initializing globals and such to the default value.

So I started reading docs, Googling and found all kinds of contradictory stuff.

information stored in the data section will increase the size of your exe.

This means that a global or static local is increasing the .exe size IF I do this, right?

char *something = NULL; // Increases the .exe size maybe 4 bytes (maybe 8 bytes on x64)
int something_else = 0; // Increases the .exe size 4 bytes

... so initializing to the default value ( 0 or NULL) is [mildly] increasing exe size unnecessarily for globals / static locals.

[mh]

Even that's not the full story. Consider FitzQuake, and consider this line in particular:

Code: Select all

byte      lightmaps[4*MAX_LIGHTMAPS*BLOCK_WIDTH*BLOCK_HEIGHT];

This is 16 MB of memory, so let's initialize it by adding "= {0};" to it. FitzQuake.exe doesn't suddenly jump to being a 16+ MB file. In fact neither the "size" nor "size on disk" propeties change at all.

To be brutally honest, I think that sweating over exe sizes in this way is micro-optimizing something that isn't even a problem to begin with. The executable is only a very very small part of the full program (think of all the libraries it needs to dynamically link to, think of all the other memory it needs to allocate) and your code may be only a very very small part of the exe (think of static libraries here). Whether it's anything in size from 400k to a coupla MB should have next to absolutely zero bearing on performance or quality of end result. We left 16-bit land behind a long time ago, so rules and philosophies that used to apply then need to be re-evaluated.

[Baker]

To be brutally honest, I think that sweating over exe sizes in this way is micro-optimizing something that isn't even a problem to begin with. The executable is only a very very small part of the full program.

That's true but understanding how the compilers work is important.

I mean I'm largely in the "just make mem 128" the default category (for now) because memory and disk size is cheap.

And a year ago, I didn't have the deep nuts and bolts of memory allocation as a short term interest.

And then I a brick-wall with the PSP and memory ... so I started looking around for anything stupid that was needlessly killing memory (external .wad support was a culprit, for instance).

I'm just saying knowing something doesn't mean you can't use it wisely.