Is uninitialized data behavior well specified?

Question

_{Note: I am using the g++ compiler (which is I hear is pretty good and supposed to be pretty close to the standard).}

---

I have the simplest class I could think of:

class BaseClass  {
  public:
    int pub;
};

Then I have three equally simple programs to create BaseClass object(s) and print out the [uninitialized] value of their data.

---

Case 1

BaseClass B1;
cout<<"B1.pub = "<<B1.pub<<endl;

This prints out:

B1.pub = 1629556548

Which is fine. I actually thought it would get initialized to zero because it is a POD or Plain Old Datatype or something like that, but I guess not? So far so good.

---

Case 2

BaseClass B1;
cout<<"B1.pub = "<<B1.pub<<endl;
BaseClass B2;
cout<<"B2.pub = "<<B2.pub<<endl;

This prints out:

B1.pub = 1629556548
B2.pub = 0

This is definitely weird. I created two of the same objects the same exact way. One got initialized and the other did not.

---

Case 3

BaseClass B1;
cout<<"B1.pub = "<<B1.pub<<endl;
BaseClass B2;
cout<<"B2.pub = "<<B2.pub<<endl;
BaseClass* pB3 = new BaseClass;
cout<<"B3.pub = "<<pB3->pub<<endl;

This prints out:

B1.pub = 0
B2.pub = 0
B3.pub = 0

This is the most weird yet. They all get initialized to zero. All I did was add two lines of code and it changed the previous behavior.

---

So is this just a case of 'uninitialized data leads to unspecified behavior' or is there something more logical going on 'under the hood'?

I really want to understand the default constructor/destructor behavior because I have a feeling that it will be very important for completely understanding the inheritance stuff..

Answer 1

So is this just a case of 'uninitialized data leads to unspecified behavior'

Yes...

Sometimes if you call malloc (or new, which calls malloc) you will get data that is filled with zeroes because it is in a fresh page from the kernel. Other times it will be full of junk. If you put something on the stack (i.e., auto storage), you will almost certainly get garbage — but it can be hard to debug, because on your system that garbage might happen to be somewhat predictable. And with objects on the stack, you'll find that changing code in a completely different source file can change the values you see in an uninitialized data structure.

About POD: Whether or not something is POD is really a red herring here. I only explained it because the question mentioned POD, and the conversation derailed from there. The two relevant concepts are storage duration and constructors. POD objects don't have constructors, but not everything without a constructor is POD. (Technically, POD objects don't have non-trivial constructors nor members with non-trivial constructors.)

Storage duration: There are three kinds. Static duration is for globals, automatic is for local variables, and dynamic is for objects on the heap. (This is a simplification and not exactly correct, but you can read the C++ standard yourself if you need something exactly correct.)

Anything with static storage duration gets initialized to zero. So if you make a global instance of BaseClass, then its pub member will be zero (at first). Since you put it on the stack and the heap, this rule does not apply — and you don't do anything else to initialize it, so it is uninitialized. It happens to contain whatever junk was left in memory by the last piece of code to use it.

As a rule, any POD on the heap or the stack will be uninitialized unless you initialize it yourself, and the value will be undefined, possible changing when you recompile or run the program again. As a rule, any global POD will get initialized to zero unless you initialize it to something else.

Detecting uninitialized values: Try using Valgrind's memcheck tool, it will help you find where you use uninitialized values — these are usually errors.