Stack execution in C

Question

For the following code

#include <stdio.h>

void f() {
  int x;
  printf("x = %d\n", x);
}

void g() {
  int y = 42;
  printf("y = %d\n", y);
}

int main() {
  f();
  g();
  return 0;
}

I get the following output

x = 22031
y = 42

If I change the order of the last two functions being executed in main() and run the code

void f() {
  int x;
  printf("x = %d\n", x);
}

void g() {
  int y = 42;
  printf("y = %d\n", y);
}

int main() {
  g();
  f();
  return 0;
}

I get the following :

y = 42
x = 42

Can someone explain this to me please.I know it has to do with the way memory is allocated in addresses but I am not sure about the details.

It's hard to describe undefined behaviour, which you get when you access an uninitialized variable. — Stephan Lechner, Nov 12 '18 at 23:27
The values are uninitialized, and therefore indeterminate. They could be anything at all. There's nothing to "explain", as it is totally at the compiler's whim. — Lee Daniel Crocker, Nov 12 '18 at 23:35
Possible duplicate of [What will be the value of uninitialized variable?](https://stackoverflow.com/q/11233602/69809) or [Why is using an uninitialized variable undefined behavior?](https://stackoverflow.com/q/11962457/69809) — vgru, Nov 12 '18 at 23:36

Niklas Rosencrantz · Answer 1 · 2018-11-12T23:32:29.590

0

You are seeing uninitialized values in memory from "something else" i.e. undefined behavior. When you run your program, you are getting and seeing "old" values in memory which come from something else than your program in your computer.

For example, the following program will experience undefined behavior because x is read before it is initialized and the value of x comes from another process:

#include <stdio.h>

int main() {
    int x;
    printf("x = %d\n", x);
    return 0;
}

edited Nov 12 '18 at 23:32

answered Nov 12 '18 at 23:29

Niklas Rosencrantz

25,640
75
229
424

I wouldn't say it's "old values from other processes" on most modern OSes. It would be a security nightmare to be able to read stuff from other programs randomly. – vgru Nov 12 '18 at 23:32
@Groo I changed it to "something else than your program".... What I meant that I thought that the value could be a leftover value from the previous time you ran your program. – Niklas Rosencrantz Nov 12 '18 at 23:34

Bwebb · Accepted Answer · 2018-11-13T00:28:48.707

x = 22031
y = 42

The X value is uninitialized stack garbage values. When your program is loaded into RAM it does not zero out stack or heap memory. Here is a reference for a C programs memory model.

The interesting case is when

y = 42
x = 42

So what is going on here? Well when you call the g function first, you pop values onto the stack (growing down in the memory model, or up if the memory model is different). The next time you call the f function the values of the uninitialized stack garbage has changed, to be what was assigned when you called g (assigning y's address to 42). This is because you have the same number of parameters and local variables pushed onto the stack in both functions, if you tweak them you will see different values. For example the following g definition may cause x to print 43 instead, depending on how the local variables get popped onto the stack.

void g() {
  volatile int z = 43;
  int y = 42;
  printf("y = %d\n", y);
}

Make the compiler doesnt optimize it out "z" if you want to mess around with this.

The Standard does not specify stacks or heaps or memory models like the one you link to; these are all implementation details that do not always hold true. — ad absurdum, Nov 12 '18 at 23:48
@DavidBowling While i dont disagree with what you said, can you link me a stack memory model that would preform different in the y=42, x=42 case? I would think that the same amount of memory is popped onto, then off, then back onto the stack in the same way "consistently" producing x=42 (with this OP example). With a single thread, i dont know of another stack memory model that would perform differently under these circumstances, although it is probably not outlined in the Standard to behave this way. To be clear, it shouldnt matter if the stack grows up or down for x=42 to be reproducible. — Bwebb, Nov 13 '18 at 00:25

Stack execution in C

2 Answers2