1

Following simple C program outputs 42 to my surprise. I expected it to output a garbage value or 0, since stack frames are different for foo() and bar(). How the output is deterministic to be 42 ?

#include <stdio.h>
void foo(void){
    int a;
    printf("%d\n",a);
}

void bar(){
    int a=42;
}

int main(){
    bar();
    foo();
    return 0;
}

>>gcc -o test test.c

>>./test

42

When I instruct compiler to optimize the code, it prints garbage!

>>gcc -O -o test test.c

>>./test

2487239847

doubleE
  • 1,027
  • 1
  • 12
  • 32
  • 6
    It is **not** deterministic. You invoke _undefined behaviour_. The code could format your harddrive. **Which** "garbage value" do you expect? – too honest for this site Feb 28 '17 at 00:47
  • A garbage value that happens to be in location in `foo()` stack where variable `a` is going to be stored. Please see the edited question. When I optimize the compiler, it prints garbage. – doubleE Feb 28 '17 at 00:50
  • Your C book should include a warning about undefined behaviour. **Read it**. So as I read your comment, any value **except** `42` is garbage. Let apart that the program is not required to print anything. – too honest for this site Feb 28 '17 at 00:55
  • 2
    Since you are reading an uninitialized value, thus invoking undefined behavior, anything is allowed to happen. So, it is no surprise the non-optimized code exhibits different behavior. It would also be no surprise if it exhibited the same behavior. – jxh Feb 28 '17 at 00:58
  • when you optimize the code, it is most likely using a register value for a, and you are just printing out what happened to be in that register. Since bar() doesn't actually do anything, the optimization would most likely skip that code. – bruceg Feb 28 '17 at 01:11
  • Possible duplicate of [Does "Undefined Behavior" really permit \*anything\* to happen?](http://stackoverflow.com/questions/32132574/does-undefined-behavior-really-permit-anything-to-happen) – kaylum Feb 28 '17 at 02:15
  • There is a problem learning with experimenting and not referring to standard, we often learn implementation specific things, just an advice, first read a good book, like C Programming : A Modern Approach 2nd Ed. – Suraj Jain Feb 28 '17 at 03:11
  • Please See This http://stackoverflow.com/a/6445794/5473170 – Suraj Jain Feb 28 '17 at 03:12

2 Answers2

2

Yes, the value 42 is a garbage. Here is the explanation for it:

Every function in stack, starts similar to this order

  1. Parameters of the function
  2. Return value of the function
  3. EBP( Which stores previous frame pointer)
  4. Exception handler frame
  5. Local variables
  6. Buffer
  7. callee save register

In the above example, main() is called and follows the procedure as above.

Then it encounters the bar() follows 1,2,3,4 steps mentioned and then stores the local variable a=42 in the memory(5) then 6,7 are followed then it will come out of the memory.

Then it encounters the foo() follows 1,2,3,4 steps as same in the memory location that bar() had. And you declared a local variable called a which will point to same memory location that bar() holding the local variable a=42. So it is giving the same value 42 when you are printing, which is actually a garbage value.

To validate this, try this example: This prints 7

#include <stdio.h>
#include <string.h>

void foo() {
    int b;
    printf("%d\n",b);
}

void zoo() {
  int dummy = 7;
}
void bar(){
    int a1=3;
}

int main(){
    bar();
    zoo();
    foo();
    return 0;
}

Ref: Doc

sreepurna
  • 1,562
  • 2
  • 17
  • 32
1

The function calls go on stack (their activation records), in this case the two functions foo and bar are identical in terms of parameters, return type and the local variables within each function. So the first call puts something on the stack and once done its activation record is popped out but not cleaned (compiler does not generate code to clean things up). Now the second function call essentially ends up using the same memory location and therefore gets the value from a previous call using same memory area. The values that are not initialized in a function are considered undefined. In the foo and bar case we got to the same value due to similar signature of two functions and same type and location of the variable. Try adding two integers or integer and a float in one function and reverse the order in next and you'll see the effects. Of course when you call the optimizer it might place things on register and as a result you may get undefined values when the compiler sees no scope for optimization as in case of foo.

Aniruddh Dikhit
  • 662
  • 4
  • 10