-1
#include<stdio.h>

void bar()
{
 int a=4;
}
void foo()
{
 int a;
 printf("%d",a);
}
int main()
{
 bar();
 foo(); 
}

I'm sure that the above program gives the output as some junk value(Thats what happenes when i compile and run). But I read in an article that it is possible for some compilers to give the output as 4 itself. The explanation given was that it is related to activation stack and activation frames. I dont understand. Is it something like the value of int a=4 from bar() function is stored somewhere in the activation stack for future use??I'm confused!!

nupadhyaya
  • 1,909
  • 1
  • 14
  • 14
  • Relevant: http://www.slideshare.net/olvemaudal/deep-c slide: 124 – this Oct 23 '13 at 18:29
  • yes!!..thats where I read it.But I dint understand how it is related to activation recored and activation frames...It is in slide 137 – nupadhyaya Oct 23 '13 at 18:33

4 Answers4

3

Don't worry about what some compilers might do. It's called "undefined behavior". Always make sure you initialize your variables to whatever you want them to be.

So again, it's pointless to try to "understand" because there's no logic, and it's certainly not "expected behavior". But, it's conceivable that some compilers would reuse a register on the cpu if the functions are inlined, so yes it could happen. If you're concerned somehow about someone running a function after yours and "stealing your value", then just set it to zero before exiting your function. But that is not "Best Practices".

In other words, even if the second function used 'b' instead of a, it could have 4 in it if they are reusing the memory space. Or some other compiler might actually preallocate in alphabetical order, so only 'a' would work. Again, it's undefined behavior.

AwokeKnowing
  • 7,728
  • 9
  • 36
  • 47
  • oh..ok.....But can you please brief me on how it happens? I mean in http://www.slideshare.net/olvemaudal/deep-c slide 137 it is given that it is related to activation record and execution stack.But how? – nupadhyaya Oct 23 '13 at 18:34
  • In other words, even if the second function used 'b' instead of a, it could have 4 in it if they are reusing the memory space. – AwokeKnowing Oct 23 '13 at 18:40
  • It is not pointless to understand. Understanding how compilers works helps to debug certain problems. It also helps to understand how programs in a more-abstract language like C are translated to more-concrete languages like assembly/machine language. While we should explain to people that certain behaviors are outside the C standard, we should not discourage seeking knowledge or understanding. – Eric Postpischil Oct 23 '13 at 18:54
  • yes, possibly. But the user said he was "confused", meaning to him, the question was about the "logic" the code itself, not the compiler. – AwokeKnowing Oct 23 '13 at 18:57
1

Function foo uses an uninitialised variable. The compiler is free to do what it likes in this situation. In practise, you might get a variable that was previously placed on the stack in a now defunct frame. It could be 4, as you say, but it could be anything else instead. Never rely on this sort of behaviour...it could be 99% reliable but go wrong on the 100th try.

Stefan
  • 8,819
  • 10
  • 42
  • 68
  • A defunct frame?? Isn't the frame popped from the stack once the function ends?Then how can there be a defunct frame? – nupadhyaya Oct 23 '13 at 18:36
  • 1
    Popping a frame just means moving the stack pointer back to the previous frame. It doesn't require that the memory is cleared. On the next call, a new frame will be allocated which overlaps the previously popped one, and therefore may have access to the old values. Possibly of use when trying to hack a system and see old values, but not of much practical use for anything else. – Stefan Oct 23 '13 at 18:43
1

To be clear it is possible that foo's a will end up with the 4 in it that bar set there (nothing to do with them having the same name BTW). But this is highly dependent on the compiler machines etc.

What you are actually doing (in foo) is 'undefined behavior', you use a without giving it a value. Undefined means the compiler may do anything, format your harddrive, print any random value including you best friends birthdate, or it could print 4.

Why might it be 4, because the way stack frames are built on many systems will results in bar writing 4 to an address and foo reading it back. The 2 functions have the same paramters, return type and number of locals so its possible that the first local will be allocated in the same memory location. THis is why you read that they could have the same value, but this is by accident not by design

BTW did you get 4 or not, probaly not

pm100
  • 48,078
  • 23
  • 82
  • 145
0

Although the two variables have the same name, they are stored in different addresses and the second a that was initialized by compiler has possibly another value than 4.

Here it looks like a, but once compiled, those two local variables are different and can't be the same.

logicbloke
  • 139
  • 3
  • 13
  • -1, How can you be sure the var a in foo won't use the same address as in bar, which can happen. – this Oct 23 '13 at 18:31
  • 1
    As LogicBloke explained, you have to think about it in terms of "scope". Both variables 'a' have function scope meaning they're no longer valid after the function ends. If you want to reuse the variable, think about making it have "global" scope. – rrirower Oct 23 '13 at 18:33
  • The bottom line is that the variable "a" in foo() and bar() are unrelated variables. In foo(), a is used uninitialized which is undefined behavior so its values can be anything, including 4. – DoxyLover Oct 23 '13 at 18:35
  • Because it's not the same thing. Values would be overridden if the same address is being used. Those are two different local variables regardless of their handle. – logicbloke Oct 23 '13 at 18:37
  • @LogicBloke: Yes, values would be overridden if the same address is used. That is not a problem; once the object’s lifetime ends, it is okay to override it. The objects are conceptually different in the computation model of the C standard. But, in actual implementation, if two functions have similar definitions of automatic objects within them, those objects within one function are likely to be assigned to the same stack addresses as objects within the other, when called with the same initial stack pointer. This is more likely with optimization disabled; optimization is likely to change it. – Eric Postpischil Oct 23 '13 at 18:52
  • Obviously, this is not behavior one should rely on. But one should understand it (for one reason because it helps to debug certain problems), and it is false to say that two different objects are necessarily stored in different addresses. – Eric Postpischil Oct 23 '13 at 18:53