Return address of local variable in C

Question

Say I have the following two functions:

1

int * foo()
{
  int b=8;
  int * temp=&b;
  return temp;
}

2

int * foo()
{
   int b=8;
   return &b;
}

I don't get any warning for the first one (e.g. function returns address of a local variable) but I know this is illegal since b disappears from the stack and we are left with a pointer to undefined memory.

So when do I need to be careful about returning the address of a temporary value?

score 21 · Accepted Answer · edited May 23 '17 at 12:00

21

The reason you are not getting a warning in the first snippet is because you aren't (from the compiler's perspective) returning an address to a local variable.

You are returning the value of int * temp. Even though this variable might be (and in this example is) containing a value which is an address of a local variable, the compiler will not go up the code execution stack to see whether this is the case.

^{Note: Both of the snippets are equally bad, even though your compiler doesn't warn you about the former. Do not use this approach.}

You should always be careful when returning addresses to local variables; as a rule, you could say that you never should.

static variables are a whole different case though, which is being discussed in this thread.

edited May 23 '17 at 12:00

Community

1
1

answered Jan 05 '12 at 13:40

Filip Roséen - refp

62,493
20
150
196

1

thanks! and the fact that When I print the return value in main it gets me the right result it actually means that it prints junk? – mary Jan 05 '12 at 13:42
3

It means that you are invoking what we normally refer to as *[undefined behavior](http://en.wikipedia.org/wiki/Undefined_behavior)*, ie. behavior that is unspecified in the standard. – Filip Roséen - refp Jan 05 '12 at 13:46

score 2 · Answer 2 · answered Jan 05 '12 at 14:38

i would say that you can return the local variable or rather pointers to such IF it was dynamically allocated by malloc, in that case the memory used for storing variable want be on stack but on heap and won't be cleared or re-used after exiting the function as it takes place in the case of automatic local variables (created without malloc), am i right?

score 0 · Answer 3 · edited May 23 '17 at 12:09

This question is probably one of the most discussed on StackO. Below, are two replies from similar threads on StackO which I found interesting, and probably made me leave this bad practice of de-referencing local variables despite the chances of me getting a wrong (undefined behavior) being very slim.

Here is a simple answer

I especially liked the this reply.

Here is an example where this bad practice caused some real hardware damage

score 0 · Answer 4 · answered Jan 05 '12 at 13:39

0

Both examples are equally incorrect. My guess is that your compiler doesn't see the danger and thus don't issue a warning when you store the address in a temporary variable.

answered Jan 05 '12 at 13:39

Lindydancer

25,428
4
49
68

score -1 · Answer 5 · answered Jan 05 '12 at 13:38

-1

These are both bad, and a good compiler should be able to detect and warn about both situations. You may get better results by turning the warning level to maximum (which you always should do anyways), and turn on optimization.

answered Jan 05 '12 at 13:38

harald

5,976
1
24
41

The specific case, maybe. But there are lots of similar cases involving shuffling the address to and from other variables (or via other functions) that a compiler simply will not be able to detect. Also, optimisation rarely increases chances of detecting such an problem - it just increases the chance of the problem having observable effects. – Rob Feb 03 '15 at 00:07
Of course there are situations the compiler can't detect, but these specific cases should be easily detectable. Optimization works because it reduces the first example to the second. – harald Feb 04 '15 at 08:45
1

Sorry, not true. There are few "shoulds" when it comes to quality of implementation of a compiler - these are vendor decisions based on their own cost/benefit analysis, which may not meet developer preconceptions. It is also very easy to construct examples (e.g. a function call that may change the pointer) that means the optimisation you claim may not be feasible - which also makes it a vendor decision on whether or not to optimise such things, not a given. – Rob Feb 04 '15 at 09:05
Of course, optimization is not part of the standard, and is therefore entirely up to the vendor. Any compiler not able to optimize away the uneccesary temporary in this example though, is worthless. Also if you read my answer it says "You *may* get better results..." Have a nice day. – harald Feb 06 '15 at 09:28

Return address of local variable in C

5 Answers5

Linked

Related