1
int *intAddr(){
  int i = 16;
  return &i;
}

char *charAddr(){
  char A = 'a';
  return &A;
}

Then I test these two function by 

int *intaddr = intAddr();printf("%d\n", *intaddr);
char *charaddr = charAddr();printf(charaddr);

But the result is that only 16 not 'a'. When the funcion intAddr() is over, the variable i is destroyed. Why the *intaddr can get 16?

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
user2326778
  • 21
  • 1

4 Answers4

4

You SHOULD NOT return a pointer to a variable that's function local. That's UNDEFINED BEHAVIOUR. DO NOT DO IT. EVER!!

The reason is that your local variable, i in this case, is destroyed when your function exits, so you pointer after your function exit will point to memory that contains at most junk.

Tony The Lion
  • 61,704
  • 67
  • 242
  • 415
  • 2
    I don't think there is need for the caps. It is important of course but I doubt caps makes it more important. – Ivaylo Strandjev Oct 30 '13 at 11:43
  • 2
    @IvayloStrandjev I think there is need for caps, because if I didn't think there was, I would not have used caps. – Tony The Lion Oct 30 '13 at 11:44
  • 2
    If you're going to emphasize something, perhaps it would be better to say **SHOULD NOT** instead of cannot -- clearly he _can_, it just doesn't work the way he expects (or in any useful way). – mah Oct 30 '13 at 11:46
  • yes, I know. If I change i = 17. The result can print 17.It seems like the i is not destroyed when the function over. – user2326778 Oct 30 '13 at 12:02
  • 1
    @user2326778 local variables have a scope constrained to the function (or block) they are defined in. That doesn't mean the memory that holds them automatically changes when that scope terminates, it means that the memory is available for use for something else and it's undefined when it will be reused -- which is why you should not do that. If you _think_ it works... you're lucky, not right. Luck runs out eventually, and generally at the worst time. – mah Oct 30 '13 at 12:06
  • 1
    @user2326778 [Stop stealing hotel room keys!](http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope/6445794#6445794) – R. Martinho Fernandes Oct 30 '13 at 12:21
1

Accessing a memory that is pointing to an element that is already destroyed invokes undefined behavior. What will happen is not defined and it is quite possible that different things happen if you run the code several times. What you do above is not much different from accessing just any address by the way.

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
0

This is just simply undefined behavior you are returning the address of an automatic variable, and so it won't exist once the function exits. Anything can happen with undefined behavior but it is not reliable. From the draft C++ standard section 6.7 Declaration statement paragraph 2 says:

Variables with automatic storage duration (3.7.3) are initialized each time their declaration-statement is executed. Variables with automatic storage duration declared in the block are destroyed on exit from the block (6.6).

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
0

Change this

int *intAddr(){
int i = 16;
return &i;}

to

int *intAddr(){
int* i = new int(16);
return i;
Sameera
  • 304
  • 1
  • 19
  • 2
    If he follows your advice his next question is going to be something like "I was doing this in a loop for a few million times, and now I've got this memory leak, how come?" --- my point being, when you might be teaching someone how to allocate memory (or any resource), always include the ramification and tell them how to return that resource. – mah Oct 30 '13 at 12:04
  • `make_shared`? Or maybe `make_unique` (you'll have to write the latter yourself)? – Aaron McDaid Oct 30 '13 at 12:06
  • 1
    Or no make_shared and no make_unique? Just return the damn thing? – R. Martinho Fernandes Oct 30 '13 at 12:23
  • Agreed, @R.MartinhoFernandes :-) Even with bigger objects, there's a lot to be said for returning by value, especially with some of the new stuff in C++11 – Aaron McDaid Oct 30 '13 at 12:25