Problem With Global Variables Initializing

[BASICFreak]

In the world of OSDev I have ran across many random issues I have never seen is userland code for *nix/Win. A lot of the time it is one of the sections of the linked file not being where the rest of the program expects. If you set the variables in the code, it will set the variable where the code THINKS it SHOULD be.

What about string constants (error messages for example)? They have to go to a .data or .rodata section (or somewhere). This isn't different from "initializing" globals. They are in fact globals. Note that I am not talking about C++ constructors here (which I wouldn't try to use).

Where do you draw a difference, from a technical point of view, between initializing globals and having string constants in your C/C++ code?

I think that if you run into issues with initialized globals, you have to address these issues whether or not you initialize globals.

I haven't ran in to the issue in a while (yes I fixed my code); and I do set global variables every now and then, but I still prefer to initialize them in code where applicable. But the issue (in my case) was the link.ld script. (which OP is not using according to first post, though another seems he may have changed that)

[TverrBjelke]

Why using init() functions instead of static global variables?

I had this problem some time ago (using c++). So excuse me for trying to explain this stuff by heart, without real code to show...

file1.c

Code: Select all

string file1 = "config.xml";

And a file2.c uses this global value also from global static scope - and expects that the value already has been set properly.

Code: Select all

string file2 =  file1;

Problem: static fields in different compilation units have no guaranteed order of setup-execution!
While you might be lucky and always see the desired setup-order, your neighbour using different version of compiler will wonder what problems are around...

So the value maybe is not yet set here in file1.c now in global-static part, but maybe file2.c gets set up 1st?
Then you might have the risk of a file2 will see a nice and legal null value, while this static biest gets initialized later with the value stated in file1.c.

Solution1:
Wait for the static initializing or usage of any static thing, by using it always only from within a function.
By then all static global variables in all compilation units are guaranteed to be set.
Often you can see a global init() call from main().

Solution2:
You use for all globally needed static variables a getter function and make use of lazy evaluation.
So the static variable is declared within a global getter-function.
That means it will be evaluated and initialized once: exactly when it comes to the 1st call of the getter function.
Any 2nd call to the getter will already have this static element readily created.
Performance penalty of a getter-function compared to a global public static variable : Well, having a call-stack.
(Think is better then having "not guaranteed behaviour" and debugging headaches later on)