5

Given a program of :

int main() { short myVariableName1; // stores from -32768 to +32767 short int myVariableName2; // stores from -32768 to +32767 signed short myVariableName3; // stores from -32768 to +32767 signed short int myVariableName4; // stores from -32768 to +32767 unsigned short myVariableName5; // stores from 0 to +65535 unsigned short int myVariableName6; // stores from 0 to +65535 int myVariableName7; // stores from -32768 to +32767 signed int myVariableName8; // stores from -32768 to +32767 unsigned int myVariableName9; // stores from 0 to +65535 long myVariableName10; // stores from -2147483648 to +2147483647 long int myVariableName11; // stores from -2147483648 to +2147483647 signed long myVariableName12; // stores from -2147483648 to +2147483647 signed long int myVariableName13; // stores from -2147483648 to +2147483647 unsigned long myVariableName14; // stores from 0 to +4294967295 unsigned long int myVariableName15; // stores from 0 to +4294967295 cout << "Hello World!" << endl; cout << myVariableName1 << endl; cout << myVariableName2 << endl; cout << myVariableName3 << endl; cout << myVariableName4 << endl; cout << myVariableName5 << endl; cout << myVariableName6 << endl; cout << myVariableName7 << endl; cout << myVariableName8 << endl; cout << myVariableName9 << endl; cout << myVariableName10 << endl; cout << myVariableName11 << endl; cout << myVariableName12 << endl; cout << myVariableName13 << endl; cout << myVariableName14 << endl; cout << myVariableName15 << endl; cin.get(); return 0; } 

Printing out the unassigned variables will print whatever was stored in that memory location previously. What I've noticed is that across multiple consecutive executions the printed values are not changing - which tells me that the locations in memory are the same each time they execute.

I'm just curious as to how this is determined, why this is so.

2
  • you are running debug or release mode? Commented Oct 12, 2012 at 16:59
  • 3
    "I'm just curious as to how this is determined" - The values are indeterminate. That means that they are not determined. Commented Oct 12, 2012 at 17:03

5 Answers 5

3

Those variables live on the stack. The execution of your program looks to be deterministic, so every time you run it the same things happen. It's not choosing the same address necessarily (many runtimes these days make use of Address Space Randomization techniques to ensure that the stack addresses are not the same between runs), but the relative addresses on the stack contain the same data every time.

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

4 Comments

Firstly thank you.second how is it possible that randomized locations contain the same data?
You still seem confused. Memory is wiped to zero before being mapped, there is no "existing contents" to the memory when a process starts running. You see non-zero data in those bytes because your program (though not your code per se) put them there. And it's the same every time because your program does the same thing every time.
If I attached an assembly debugger then I should be able to see those memory locations set to those values?
Yes, but it will be difficult. Dynamically linked linux programs actually start execution in ld.so and run a significant amount of code before calling _start (which calls main). You'd need to do some research about setting breakpoints there, I don't know how off hand.
3

They can be anything don't rely on them to be anything specific.
Technically, the values are Indeterminate.

Note that using an Indeterminate value results in Undefined Behavior.

3 Comments

This is confusing things more than helping. Your use of "indeterminate" and "undefined" refers to the C language specification. The poster has a real machine, with real values stored in real memory. The question was why those values are the same between runs. Saying they are "undefined" without reference to what you mean (clearly the memory contents are real and quite well defined!) doesn't answer the question.
@AndyRoss: The real machine, with real values stored in real memory doesn't make the behavior deterministic in any possible way.The behavior is Undefined as per the Standard and that is the only correct explanation.
A real machine's behavior is not deterministic? I think you're confused about how computers work, and I'm certain you're confused about my criticism. It's fine to argue a design point based on a language standard. But that's not what the question was about.
3

They're all stack based. Probably the startup code has already used those locations, so you're getting whatever it left in them.

2 Comments

+1 especially as when one uses cout there is some initialization ongoing to build all those static objects.
Thanks! So by that theory changing the order they are initialized in should yield the same results a long as the sizeof is the same?
2

The behaviour is not defined as "whatever was stored in that memory location previously", but it is rather not defined at all. There is no guarantee to what will happen.

My best guess is that your operation system is using virtual memory (as most modern OS do), thus giving you the same memory addresses every time.

2 Comments

The fact that the address in memory is the same does not explain why the content at that address would be the same.
The virtual memory bit isn't relevant to memory mapping address choices. In fact it's increasingly common for mappings to be semi-randomized at runtime. But the addresses aren't the issue anyway -- the symptom the OP is seeing is that the contents of the memory are the same between runs, not the addresses. Memory content is never retained from one process to another in a modern OS.
2

Unlike humans, computers are deterministic.

Usually a good idea to use the compiler options to pick up when reading a variable that has not been given a value.

So the OS picks up the code and does exactly the same thing ever time. Hence the same result.

But if you start fiddling with the code the executable will be different. As you have not been specific you get a different result the next time around.

So in summary just use all the features of the compiler to help you spot this error and get into the habit of giving the variables values before using that variable.

1 Comment

I actually did this on purpose and after executing several times noticed the values were not changing. Being so I was curious as to how the memory address were being assigned to the variables. Thanks for the help!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.