27

I've checked myself, I wrote a program like this

int main() { int i; cout << i; return 0; }

I ran the program a few times and the result was same all the time, zero. I've tried it in C and the result was the same.

But my textbook says

If you don’t initialize an variable that’s defined inside a function, the variable value remain undefined.That means the element takes on whatever value previously resided at that location in memory.

How's this possible when the program always assign a free memory location to a variable? How could it be something other than zero (I assume that default free memory value is zero)?

Improve this question
6
  • 8
    It is undefined behavior in C++ and C. You said C in the title but cout is from C++. Commented May 11, 2015 at 16:03
  • And because it´s undefined, the compiler "may" (mut not must) generate the program so that 0 is assigned before you use it. Commented May 11, 2015 at 16:06
  • 1
    How were you able to try cout in C? Commented May 11, 2015 at 20:59
  • 1
    @Daenie I used printf but I was too lazy to paste C code Commented May 12, 2015 at 4:23
  • 1
    Related: Where do the values of uninitialized variables come from, in practice on real CPUs? Commented Dec 10, 2023 at 20:56

6 Answers 6

Reset to default
28

How's this possible when the program always assign a free memory location to a variable? How could it be something rather than zero?

Let's take a look at an example practical implementation.

Let's say it utilizes stack to keep local variables.

void foo(void) { int foo_var = 42; } void bar(void) { int bar_var; printf("%d\n", bar_var); } int main(void) { bar(); foo(); bar(); }

Totally broken code above illustrates the point. After we call foo, certain location on the stack where foo_var was placed is set to 42. When we call bar, bar_var occupies that exact location. And indeed, executing the code results in printing 0 and 42, showing that bar_var value cannot be relied upon unless initialized.

Now it should be clear that local variable initialisation is required. But could main be an exception? Is there anything which could play with the stack and in result give us a non-zero value?

Yes. main is not the first function executed in your program. In fact there is tons of work required to set everything up. Any of this work could have used the stack and leave some non-zeros on it. Not only you can't expect the same value on different operating systems, it may very well suddenly change on the very system you are using right now. Interested parties can google for "dynamic linker".

Finally, the C language standard does not even have the term stack. Having a "place" for local variables is left to the compiler. It could even get random crap from whatever happened to be in a given register. It really can be totally anything. In fact, if an undefined behaviour is triggered, the compiler has the freedom to do whatever it feels like.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Since this example invokes undefined behavior, you should mention the exact compiler and compiler setting that you used to reproduce the observed behavior.
15

If you don’t initialize an variable that’s defined inside a function, the variable value remain undefined.

This bit is true.

That means the element takes on whatever value previously resided at that location in memory.

This bit is not.

Sometimes in practice this will occur, and you should realise that getting zero or not getting zero perfectly fits this theory, for any given run of your program.

In theory your compiler could actually assign a random initial value to that integer if it wanted, so trying to rationalise about this is entirely pointless. But let's continue as if we assumed that "the element takes on whatever value previously resided at that location in memory"…

How could it be something rather than zero(I assume that default free memory value is zero)?

Well, this is what happens when you assume. :)

Improve this answer

1 Comment

Additionally, some compilers might remove memory access entirely, in which case you will be accessing register values instead.
5

This code invokes Undefined Behavior (UB), since the variable is used uninitialized.

The compiler should emit a warning, when a warning flag is used, like -Wall for example:

warning: 'i' is used uninitialized in this function [-Wuninitialized] cout << i; ^

It just happens, that at this run, on your system, it had the value of 0. That means that the garbage value the variable was assigned to, happened to be 0, because the memory leftovers there suggested so.

However, notice that, kernel zeroes appear relatively often. That means that it is quite common that I can get zero as an output of my system, but it is not guaranteed and should not be taken into a promise.

Improve this answer

2 Comments

I like your mention of compiler flags like -Wall
"It so happens that your compiler gives you a program that outputs an arbitrary int", the standard permits any observable behaviour from that whole program.
4 
int i; cout << i;

Since C++26, this is erroneous behavior. i is default-initialized, which means that no initialization is performed, and it has erroneous value. This means that i could have e.g. value 0 (or some other value), but you're not really supposed to use it.

When it is being accessed in cout << i, that is erroneous behavior. The program could just print the value of i and move on as usual, but it could also crash as the result of printing i. Also, the compiler should give you a warning.

Prior to C++26, this is undefined behavior, as explained by the other answers. Note that the value 0 is particularly likely, even when the memory is considered indeterminate or erroneous by C++. This happens because the operating systems regularly fill pages with zero, therefore you can often get zeros by coincidence.

See also What is erroneous behavior? How is it different from undefined behavior?, and Where do the values of uninitialized variables come from, in practice on real CPUs?

Improve this answer

Comments

3

Static variables and global variables are initialized to zero:

Global: int a; //a is initialized as 0 void myfunc(){ static int x; // x is also initialized as 0 printf("%d", x);}

Where as non-static variables or auto variables i.e. the local variables are indeterminate (indeterminate usually means it can do anything. It can be zero, it can be the value that was in there, it can crash the program). Reading them prior to assigning a value results in undefined behavior.

void myfunc2(){ int x; // value of x is assigned by compiler it can even be 0 printf("%d", x);}

It mostly depends on compiler but in general most cases the value is pre assumed as 0 by the compliers

Improve this answer

Comments

0

How's this possible when the program always assign a free memory location to a variable? How could it be something other than zero (I assume that default free memory value is zero)?

There is no default "free" value in memory. Memory chips just contain "static" until they are powered and something is written to them. Depending on which bits of the chip you get, they get interpreted as numbers and one might be 0. It's a coin toss what you get.

That said, many operating system kernels, for security reasons, clear memory before they hand it to your app. After all, imagine your program is run after someone used sudo; the memory you get might still contain a token that will let your program get superuser rights.

However, that only applies to the first time a bit of memory is given to your program. If you later delete it and allocate another block of same or smaller size, your malloc library might choose to just re-use that block instead of asking the kernel for more memory, and will not clear it to 0.

And that's just heap memory. On the stack, values from previous functions may still be present. But also, at initial startup, the OS (or some of the initialization code that runs before main, like constructors for global objects, or some housekeeping code your operating system runs to e.g. set up new) might have left numbers or zeroes on the stack, and since that code runs each time at startup, might do so consistently.

The stack is like an array with a maximum size. The entire stack is reserved for your thread by the kernel, and then it remembers how many items are on the stack. If you push 1, 0 and 2 on the stack, then take them off again, and then request space for 3 variables, they will still contain 1, 0 and 2. Because C doesn't clear memory (it would be a waste of time if you then immediately assign it a value afterwards), and this area is reserved for your stack, so nobody else will re-use it.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.