I made a small test to see how the stack is used in a C application.
#include <stdio.h>
void a(void)
{
int a = 0;
}
void b(void)
{
int b;
printf("%i\n", b++);
}
int main(void)
{
a();
b();
b();
b();
fflush(stdin), getc(stdin);
return 0;
}
Isn't b allocated in the same place on the stack where a was? I would expect the output to be 0 1 2, but instead I get the same garbage value three times. Why is that?
About the only way to get a definitive answer about why you're getting what you're getting is to get the assembly language output from the compiler and see what it's doing. At a guess, the entirety of a() is being removed as dead code, and b is probably being allocated in a register, so even if a had been allocated and initialized, there'd still be a fair chance that b wouldn't end up in the same storage.
From a viewpoint of the language, there's not really any answer -- your code simply has undefined behavior from using an uninitialized variable. Just to add insult to injury, your fflush(stdin) also causes undefined behavior, so even if the rest of the code made some sense, you still wouldn't have any guarantee about what output it would produce.
I might guess that you got all zeroes as output, but this is not necessarily the case. In function b, you are declaring a new int b which is created for each execution of the code. B is uninitialized in your code, but some compilers will zero this value. This is not standard, and should NOT be counted on. You should always initialize your variables.
As far as the stack goes, that is implementation specific and dependent upon the compiler, optimizer settings, etc. There is no guarantee that this variable ever lives on the stack. Chances are it does not, given the short duration of scope it may just live in a CPU register.
In the above code b and a are completely independent variables, and thus should not be counted on to have the same value, even if they are stored in the same memory location.
What you are doing is invoking undefined behaviour, except in C99 where the value is indeterminate. Either way you don't know exactly what will happen.
There are no guarantees about the condition of the stack when you leave a method, nor what value uninitialized variables will have.
The assignement that is part of b++ in your function b() must not necessarily be performed by the compiler since b is not read afterwards. But what is more important here is if you don't have an initializer:
The initial value of the object is indeterminate.
that's it. (Not UB, as other say.) The compiler is free to implement this in any way of his liking.
NB: The word "stack" doesn't appear anywhere in the C standard. Whereas this a convenient concept to implement auto variables in C, there is no obligation for the compiler to use that concept for a given variable, and in particular there is no obligation at all to store a variable in memory. It can well just hold all variables in registers, if the platform allows for that. So if you'd look into the assembler that is produced for a() you most probably just see nothing, just an empty return.
Have you read these slides already?
http://www.slideshare.net/olvemaudal/deep-c
There is some discussion about stack behaviour like this. Of course you can never rely on the value in an auto variable. The compiler is free to put these variables on registers. Or on the stack.
B's value is indeterminate. You can't learn anything by running this program.
Related
#include <stdio.h>
int main()
{
int a;
const int b = a;
printf("%d %d\n", a, b);
return 0;
}
The same code I tried to execute on onlinegdb.com compiler and on Ubuntu WSL. In onlinegdb.com, I got both a and b as 0 with every run, whereas in WSL it was a garbage value. I am not able to understand why garbage value is not coming onlinegdb.com
Using int a; inside a function is described by C 2018 6.2.4 5:
An object whose identifier is declared with no linkage and without the storage-class specifier static has automatic storage duration, as do some compound literals…
Paragraph 6 continues:
… The initial value of the object is indeterminate…
An indeterminate value is not an actual specific value but is a theoretical state used to describe the semantics of C. 3.19.2 says it is:
… either an unspecified value or a trap representation…
and 3.19.3 says an unspecified value is:
… valid value of the relevant type where this document imposes no requirements on which value is chosen in any instance…
That “any instance” part means that the program may behave as if a has a different value each time it is used. For example, these two statements may print different values for a:
printf("%d\n", a);
printf("%d\n", a);
Regarding const int b = a;, this is not covered explicitly by the C standard, but I have seen a committee response: When an indeterminate value is assigned (or initialized into) another object, the other object is also said to have an indeterminate value. So, after this declaration, b has an indeterminate value. The const is irrelevant; it means the source code of the program is not supposed to change b, but it cannot remedy the fact that b does not have a determined value.
Since the C standard permits any value to be used in each instance, onlinegdb.com conforms when it prints zero, and WSL conforms when it prints other values. Any int values printed for printf("%d %d\n", a, b); conform to the C standard.
Further, another provision in the C standard actually renders the entire behavior of the program undefined. C 2018 6.3.2.1 2 says:
… If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.
This applies to a: It could have been declared register because its address is never taken, and it is not initialized or assigned a value. So, using a has undefined behavior, and that extends to the entire behavior of the program on the code branch where a is used, which is the entire program execution.
I am not able to understand why garbage value is not coming
This is a very strange statement. I wonder: what kind of answer or explanation do you expect you might get? Something like:
Everyone who said that "uninitialized local variables start out containing random values" lied to you. WSL was wrong for giving you random values. You should have gotten 0, like you did with onlinegdb.com.
onlinegdb.com is buggy. It should have given truly random values.
The rules for const variables are special. When you say const int b = a;, it magically makes a's uninitialized value more predictable.
Are you expecting to get an answer like any of those? Because, no, none of those is true, none of those can possibly be true.
I'm sorry if it sounds like I'm teasing you here. I agree, it's surprising at first if an uninitialized local variable always starts out containing 0, because that's not very random, is it?
But the point is, the value of an uninitialized local variable is not defined. It is unspecified, indeterminate, and/or undefined. You cannot know what it is going to be. But that means that no value — no possible value — that it contains can ever be "wrong". In particular, onlinegdb.com is not wrong for not giving you random values: remember, it's not obligated to give you anything!
Think about it like this. Suppose you buy a carton of milk. Suppose it's printed on the label, "Contents may spoil — keep refrigerated." Suppose you leave the carton of milk on the counter overnight. That is, suppose you fail to properly refrigerate it. Suppose that, a day later, you realize your mistake. Horrified, you carefully open the milk carton and take a small taste, to see if it has spoiled. But you got lucky! It's still okay! It didn't spoil!
Now, at this point, what do you do?
Hastily put the milk in the refrigerator, and vow to be more careful next time.
March back to the store where you bought the milk, and accuse the shopkeeper of false advertising: "The label says 'contents may spoil', but it didn't!!" What do you think the shopkeeper is going to say?
This may seem like a silly analogy, but really, it's just like your C/C++ coding situation. The rules say you're supposed to initialize your local variables before you use them. You failed. Yet, somehow, you got predictable values anyway, at least under one compiler. But you can't complain about this, because it's not causing you a problem. And you can't depend on it, because as your experience with the other compiler showed you, it's not a guaranteed result.
Typically, local variables are stored on the stack. The stack gets used for all sorts of stuff. When you call a function, it receives a new stack frame where it can store its local variables, and where other stuff pertaining to that function call is stored, too. When a function returns, its stack frame is popped, but the memory is typically not cleared. That means that, when the next function is called, its newly-allocated stack frame may end up containing random bits of data left over from the previous function whose stack frame happened to occupy that part of stack memory.
So the question of what value an uninitialized local variable contains ends up depending on what the previous function might have been and what it might have left lying around on the stack.
In the case of main, it's quite possible that since it's the first function to be called, and the stack might start out empty, that main's stack frame always ends up being built on top of virgin, untouched, all-0 memory. That would mean that uninitialized variables in main might always seem to start out containing 0.
But this is not, not, not, not, not guaranteed!!!
Nobody said the stack was guaranteed to start out containing 0. Nobody said that there wasn't some startup code that ran before main that might have left some random garbage lying around on the stack.
If you want to enumerate possibilities, I can think of 3:
The function you're wondering about is one that always gets called first, or always gets called at a "deep leaf" of the call stack, meaning that it always gets a brand-new stack frame, and on a machine where the stack always starts out containing 0. Under these circumstances, uninitialized variables might always seem to start out containing 0.
The function you're wondering about does not always get a brand-new stack frame. It always gets a "dirty" stack frame with some previous function's random data lying around, and the program is such that, during every run, that previous function was doing something different and left something different on the stack, such that the next function's uninitialized local variables always seem to start out containing different, seemingly random values.
The function you're wondering about is always called right after a previous function that always does the same thing, meaning that it always leaves the same values lying around, meaning that the next function's uninitialized local variables always seem to start out with the same values every time, which aren't zero but aren't random.
But I hope it's obvious that you absolutely can't depend on any of this! And of course there's no reason to depend on any of this. If you want your local variables to have predictable values, you can simply initialize them. But if you're curious what happens when you don't, hopefully this explanation has helped you understand that.
Also, be aware that the explanation I've given here is somewhat of a simplification, and is not complete. There are systems that don't use a conventional stack at all, meaning that none of those possibilities 1, 2, or 3 could apply. There are systems that deliberately randomize the stack every time, either to help new programs not to accidentally become dependent on uninitialized variables, or to make sure that attackers can't exploit certain predictable results of a badly written program's undefined behavior.
When your operating system gives your program memory to work with, it will likely be zero to start (though not guaranteed). As your program calls functions it creates stack frames, and your program will effectively go from the .start assembly function to the int main() c function, so when main is called, no stack frame has written the memory that local variables are placed at. Therefore, a and b are both likely to be 0 (and b is guaranteed to be the same as a). However, it's not guaranteed to be 0, especially if you call some functions that have local variables or lots of parameters. For instance, if your code was instead
#include <stdio.h>
void foo()
{
int x = 42;
}
int main()
{
foo();
int a;
const int b = a;
printf("%d %d\n", a, b);
return 0;
}
then a would PROBABLY have the value 42 (in unoptimized builds), but that would depend on the ABI (https://en.wikipedia.org/wiki/Application_binary_interface) that your compiler uses and probably a few other things.
Basically, don't do that.
I found out something hilarious problem in C.
Here is my Code
#include <stdio.h>
void method()
{
int indx;
printf("%d\n", indx);
indx++;
}
int main(void)
{
method();
method();
method();
}
This is simple example.
indx variable is not initialized. So, The result of printf in method function would be something strange value.
And indx is local variable. So indx++ is useless.
But The answer is
0
1
2
It seems like that indx is remain
I can't understand. why?
Local variables are stored on the stack. Because you are doing no other action between each function call, the stack is essentially preserved (unaltered) between calls, and the lack of initialisation means that the value of indx is whatever happens to be stored in that stack location.
If you made other function calls, the stack might well be overridden, resulting in non-sequential values, and likely not starting from zero.
One reason why the stack might contain zero values at startup can be because, depending on compiler, compiler options and standard library startup, the stack might be deliberately initialised to zero (or just because the region of memory used happens to contain zeros from a previous application etc).
One should never rely on such behaviour, it is specifically undefined behaviour, and thus initialising variables and ensuring you understand variable scope is an important thing to learn in software development.
I think there are plenty of descriptions of how stack is used in software development languages (and variability across hardware architectures and implementations) that you should research that separately.
The local variables are especially stored in the memory area of the corresponding function, hence you can see the increment of the indx value by single value each time the function is called.
But the answer returns the memory values of the stored variable.
So I was messing up with dynamic memory and pointers, and I was wondering how C was managing the stack when it comes to pointers that points to local variables.
I came out with this simple function :
int* dummy(){
int test = 4;
int *t2;
t2 = &test;
return t2;
}
This function initialize a pointer, and an int as a local variable (should not be accessible outside of my function, as the stack state will be restored once I get out of the function). However, I am returning the pointer as the result of my function.
I can get the pointer back and print the value of my local variable with :
#include <stdio.h>
int main(void){
int* p = dummy();
// some other calls to other functions to mess up the bellow stack,
// where my local variable "test" was supposed to be landing
printf("%d\n", *p); // printing the value of "test" (which is 4)
}
Result
$ ./a.out
4
Why is this printing the correct result? Isn't the pointer pointing at a variable in a stack from an other state? I am confused.
If the memory stays somewhere without dynamic allocation, where does it stay? Is it lost forever? (no way to "free" it)
EDIT after the comments
The behavior is undefined. Adding compiler options for warning such as pedantic will print a warning that I am returning a pointer pointing at a local variable, and the executable gets bugus.
The reason for this is that dummy's stack state get lost when the program exists the function, thus not assuring the value of local variables, because they are... local.
One of the possible outcomes of undefined behavior is - behaving as expected.
Once dummy returns, test no longer exists - logically speaking. However, the region of the stack it occupied may not be immediately overwritten, so that value may persist in that (virtual) location for some time afterwards.
The pointer is invalid - we’re using it to access an object outside of that object’s lifetime - so the behavior is definitely undefined. But that doesn’t mean that the value must be something other than 4.
Undefined behavior is undefined. There is no value this program can print that is, in any sense, "correct". What's confusing you is that you think there is some "correct" value this program can print and therefore you wonder why it's printing the "correct" value.
The problem is entirely in your incorrect understanding that some value is more "correct" than some other value. All values are equally "correct" for this program.
I was wondering how C was managing the stack when it comes to pointers that points to local variables
It does not. C does not even require a stack. What you are doing is undefined behavior which means that the C standard does not impose ANY requirements on the compiler.
So the answer to your question has nothing to do with the C standard. It can be boiled down to "how it's usually handled". But when you do stuff like it is, as I mentioned, undefined behavior. So this kind of code is likely to be messed up as soon as you turn on any compiler optimizations.
It's possible to make educated guesses about the behavior, but you have no guarantees.
Actually, it's kind of like looking into your neighbours window and be surprised that it's the same neighbour you've had for years. In the exact same way, you have no guarantees that your neighbour has not suddenly moved and someone else have moved in. Well, in your case, this happened. Your neighbour have not moved out yet.
#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!!
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.
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
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.
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.
We know that automatic variables are destroyed upon the return of the function.
Then, why is this C program returning correct value?
#include <stdio.h>
#include <process.h>
int * ReturningPointer()
{
int myInteger = 99;
int * ptrToMyInteger = &myInteger;
return ptrToMyInteger;
}
main()
{
int * pointerToInteger = ReturningPointer();
printf("*pointerToInteger = %d\n", *pointerToInteger);
system("PAUSE");
}
Output
*pointerToInteger = 99
Edit
Then why is this giving garbage values?
#include <stdio.h>
#include <process.h>
char * ReturningPointer()
{
char array[13] = "Hello World!";
return array;
}
main()
{
printf("%s\n", ReturningPointer());
system("PAUSE");
}
Output
xŤ
There is no answer to that question: your code exhibits undefined behavior. It could print "the right value" as you are seeing, it could print anything else, it could segfault, it could order pizza online with your credit card.
Dereferencing that pointer in main is illegal, it doesn't point to valid memory at that point. Don't do it.
There's a big difference between you two examples: in the first case, *pointer is evaluated before calling printf. So, given that there are no function calls between the line where you get the pointer value, and the printf, chances are high that the stack location pointer points to will not have been overwritten. So the value that was stored there prior to calling printf is likely to be output (that value will be passed on to printf's stack, not the pointer).
In the second case, you're passing a pointer to the stack to printf. The call to printf overwrites (a part of) that same stack region the pointer is pointing to, and printf ends up trying to print its own stack (more or less) which doesn't have a high chance of containing something readable.
Note that you can't rely on getting gibberish either. Your implementation is free to use a different stack for the printf call if it feels like it, as long as it follows the requirements laid out by the standard.
This is undefined behavior, and it could have launched a missile instead. But it just happened to give you the correct answer.
Think about it, it kind of make sense -- what else did you expect? Should it have given you zero? If so, then the compiler must insert special instructions at the scope end to erase the variable's content -- waste of resources. The most natural thing for the compiler to do is to leave the contents unchanged -- so you just got the correct output from undefined behavior by chance.
You could say this behavior is implementation defined. For example. Another compiler (or the same compiler in "Release" mode) may decide to allocate myInteger purely in register (not sure if it actually can do this when you take an address of it, but for the sake of argument...), in that case no memory would be allocated for 99 and you would get garbage output.
As a more illustrative (but totally untested) example -- if you insert some malloc and exercise some memory usage before printf you may find the garbage value you were looking for :P
Answer to "Edited" part
The "real" answer that you want needs to be answered in disassembly. A good place to start is gcc -S and gcc -O3 -S. I will leave the in-depth analysis for wizards that will come around. But I did a cursory peek using GCC and it turns out that printf("%s\n") gets translated to puts, so the calling convention is different. Since local variables are allocated on the stack, calling a function could "destroy" previously allocated local variables.
Destroying is the wrong word imho. Locals reside on the stack, if the function returns the stack space may be reused again. Until then it is not overwritten and still accessible by pointers which you might not really want (because this might never point to something valid)
Pointers are used to address space in memory, for local pointers the same as I described in 1 is valid. However the pointer seems to be passed to the main program.
If it really is the address storing the former integer it will result in "99" up until that point in the execution of your program when the program overwrite this memory location. It may also be another 99 by coincidence. Any way: do not do this.
These kind of errors will lead to trouble some day, may be on other machines, other OS, other compiler or compiler options - imagine you upgrade your compiler which may change the behaviour the memory usage or even a build with optimization flags, e.g. release builds vs default debug builds, you name it.
In most C/C++ programs their local variables live on the stack, and destroyed means overwritten with something else. In this case that particular location had not been overwritten yet when it was passed as a parameter to printf().
Of course, having such code is asking for trouble because per the C and C++ standards it exhibits undefined behavior.
That is undefined behavior. That means that anything can happen, even what you would expect.
The tricky part of UB is when it gives you the result you expect, and so you think that you are doing it right. Then, any change in an unrelated part of the program changes that...
Answering your question more specifically, you are returning a pointer to an automatic variable, that no longer exists when the function returns, but since you call no other functions in the middle, it happens to keep the old value.
If you call, for example printf twice, the second time it will most likely print a different value.
The key idea is that a variable represents a name and type for value stored somewhere in memory. When it is "destroyed", it means that a) that value can no longer be accessed using that name, and b) the memory location is free to be overwritten.
The behavior is undefined because the implementation of the compiler is free to choose what time after "destruction" the location is actually overwritten.