Well, I don't really care much (if at all) about why that happens because I find no interest in the topic. I mean, if I were testing a compiler (that I may have done), then yes, I could be interested in finding out. Sorry if it sounds b*tchy; it's not. :-P What I mean is: It is a topic that goes beyond my programming interest and therefore I have no answer. I also say: This is probably something for a compiler expert, or a C++ expert that may have had to deal with stuff like this during some weird debugging scenario.
When your variable point to a memory allocation that has been de-allocated, you cannot depend on it's value still there. In your case it is possible the value is still there on the stack but it is no guarantee. If you take your program and compile in another PC or server, the value can be garbage and not 8.
I was also thinking your program is so short so after return from the function call, no other code will be using that memory so the value 8 is still there and when you print it shows 8.
The second call of printf() will print garbage because the previous call of printf has used the stack.
The first call of printf() prints 8 because at that time that particular section of the stack is not modified.
on the other side: why do you feel surprised that something wrong happens when you do something wrong?
@coder777 Excellent answer that shows you have a good knowledge of how the memory is managed.
@webJose I do not understand why you are posting an answer to this topic if you do not care at all. The fact that a topic goes beyond your programming interest (I would say knowledge instead of interest) does not mean that it is not interesting. In my opinion, it is a very good ideal to find a root case for a problem because that way you can learn a lot and that is what it takes to become an expert.
Your post sounds b*tchy and it IS b*tchy.
I disagree. I find webJose's attitude to be correct. If you already know that you're doing something that produces undefined behavior, it doesn't actually matter why that undefined behavior produces the results it produces, unless you're interested in that from a pure scientific point of view. In practical software development, what matters is to fix the code that produces the undefined behavior, not to fix the undefined behavior itself.
If you don't know where the undefined behavior is, knowing where the behavior becomes erroneous will generally not tell you much about what caused it.
Try to find the answer to the question why will teach you a lot and it is not a pure scientific point of view.
In this specific case, mailkamlesh was trying to find out why two printf calls with the same parameters one right after the other were printing different thing and in HIS opinion one of them was right and the other one wrong.
In this scenario, it is perfectly valid try to find out why the undefined behavior produces the results it produces. In fact he has learned something that probably will save him a lot of time troubleshooting code in the future.
In my opinion, knowing exactly why things happen is what makes the difference between a good and an excellent professional.
I am afraid I will have to disagree here - the behavior was, in this case, undefined. That's all you need to know. Knowing why there is a difference between undefined case 1 and undefined case 2 is, in my opinion, completely useless.
@helios
I wouldn't say that. Imagine you have an issue like: The first time the pointer results the right value and after that just garbage. Then you know what to look for and it's very limited where it happend (where the pointer is somehow involved).
Undefined behavior: yes. Random behavior (with exact the same system/compiler): often no.
In fact he has learned something that probably will save him a lot of time troubleshooting code in the future.
Not really. The real problem in debugging is not finding the type of bug you're looking at (99% of the time it's memory corruption), but where the error happened.
Let's suppose you've somehow managed to figure out that the error is being generated by returning a pointer to a local object (in itself, quite a feat). You still don't know which of the thousands of functions actually returned the pointer. Working backwards from an illegal access is very hard. It's much easier to work forward from a good program state and try to find where it goes wrong, and knowing that something wrong was returned from somewhere doesn't help anywhere near as much as, say, "this object has an invalid value".
In this scenario, it is perfectly valid try to find out why the undefined behavior produces the results it produces. In fact he has learned something that probably will save him a lot of time troubleshooting code in the future.
unless he has learnt that you can't trust memory that you don't own, he hasn't learnt anything.
With all due respect to coder777, his answer isn't correct. The best you can say is that, in the OPs case, when the first function evaluated the address it had not been overwritten and in the second it had. The same code compiled for release with VS2010 prduced the output
@hanst99
As a matter of fact, knowledge is never too much and if you do not agree with me is your problem not mine.
“the behavior was, in this case, undefined. That's all you need to know”
It is true if you a narrow minded person who is not interested in learning how his compiler/system behaves under certain non-ideal situation. That kind of knowledge is the one that helps you when troubleshooting and application.
Generally speaking, people ask thing in the forum because they want to learn and I do not thing that webJose’s answer will teach them something.
Let me phrase it like this - it is pretty much pointless to know what your calculator does when you attempt to make it divide by zero, because no matter what the result is, it is not a useful one. The same thing goes for this case.
That is the user point of view and here we are the designers, and for the designer it is very important to know as much as possible about his tool and his system.
Listen, I am not trying to make you guys to agree with my way of thinking. What I am trying to do is to point that webJose post is not an answer for the topic, actually it is not even constructive.
Unless you are in the C++ standard committee or working on a compiler, you are a 'user' in respect to the C++ language. As I and others here have pointed out, there is no way you could possible generate useful information from undefined behavior.
Well, if you don't find my post constructive, then by all means dedicate your time an effort in finding a solution here. Just note that I never said the topic was not interesting, I just said it was not interesting to me. And last I checked we live in a virtual world where opinions can be freely expressed, opinions such as yours and mine.
Feel free to disagree with me all you want, just don't put words in my mouth.
And now let me ask you, gaorozcoo, if your gracefulness allows me: How good will cracking the why of this predicament help in coding correctly? I'll leave you with my answer, which you can consider a mere opinion: No good. The bottom line is that the code is ill-formed and must be corrected because you must NEVER try to access memory that is not allocated. And that's helpful because it lets the coder produce high quality software.