Thread: return local variable

It is said that, you should not return value that is created on stack. i.e the auto variable or the local variables. Can anyone tell me how the program below prints the right value "hi"???
char* foo() {
char x[10] ;
strcpy( x, "hi");
return x;
}
int main(){
char *f;
f = foo();
printf( "%s", f);
}


Sorry that my code isn't tagged but I'm in too big a hurry to read http://cboard.cprogramming.com/showthread.php?t=25765

Code:

f = foo();

is expecting a pointer to type char to be returned. And while an array name without a subscript is technically the address of the array, it needs to be dereferenced to be returned.

Code:

#include <stdio.h>

char * foo(void);

int main()
{
    char *f;
    
    f = foo();
    printf( "%s", f);

    return 0;
}

char * foo(void) 
{
    char *x;
    strcpy( x, "hi");
    
    return x;
}

It just so happens that this works for your compiler in this particular case. The array x is only valid in the function where it is declared. The fact that the memory locationstill happens to be set to "hi" after the function returns is simply because the computer hasn't had the need to overwrite it yet - but that is not guaranteed. The best way to pass a string out of a function is like this:

Code:

void foo(char f[]) 
{
  strcpy( f, "hi");
}

int main(void)
{
  char f[10];
  foo(f);
  printf( "%s", f);

  return 0;
}

An alternative way is this:

Code:

char* foo() 
{
  char * x = malloc(10*sizeof(*x)) ;
  strcpy( x, "hi");
  return x;
}

int main(void)
{
  char *f;
  f = foo();
  printf( "%s", f);

  free(f);

  return 0;
}

But (in my opinion) the 2nd way is dangerous because you are malloc()ing and free()ing in different functions and could forget for one branch of the code leading to memory leaks. Go with the 1st way.

Scribbler: your foo() function writes to a random, unallocated memory location - that is a memory leak.

edit:: must learn to type faster...

hey, I tried the same program with an additional int definition in the function foo. Now the data is getting corupted. Why is that?

This is exactly why this is bad code. It only worked before because of a fluke in the way the compiler works. The moral of the story - write code properly.

Originally Posted by sangi

I understand that. I only want to know why an additional variable will overwrite the next variable in the stack??

It has nothing to do with that variable. The code you wrote has an undefined behaviour in C. That's it. It now all depends on how the generated code looks like.
I.e. your first piece of code did not work on my system at all. It printed lots of garbage. After compiling it again with different optimization model, the code "worked". Your second example works for me too - but again only on that specific optimization level.

If you, for whatever reason, really want to know why it works without that integer but not with it, you will need to tell your compiler to generate an object as assembler output instead of a binary version. Or even better, run the programm with a debugger that can step through assembler code like ddd. I guess MS Visual Cxx can do the same. Then see what the value of %eax is when foo() returns and monitor the data at that location in memory while stepping through the code. You might also want to use a string longer than "hi" because any serious compiler will optimize that to an integer constant which might or might not make things harder for you.

Oh I'm fully aware that the code I left was total fud. I merely tweaked the original code to show 'how' to pass that information back. If you wanted it a bit more reliable I woulda written like this

Code:

#include <stdio.h>

char *foo();

int main()
{
    
    char *f;
    
    f = foo();
    printf( "%s", f);

    return 0;
}

char *foo() 
{
    static char x[] = "goodbye";
    strcpy( x, "hi");
    
    return x;
}

Which would make x a static variable, which doesn't die upon function completion.

Think of the stack as a pile of dishes. When you call a function, you put a piece of paper on top of the stack and then put a plate on the pile for each argument you pass to the function and each automatic variable defined inside the function. So the piece of paper in the pile of plates marks how big the stack was before the function was called. Then you can do whatever you want with the plates that are on top of the piece of paper when you're inside the function. When the function exits, all the plates on top of the piece of paper are taken away and discarded. This is where your string is that you're trying to return. You're returning a pointer to a plate that's been taken away. If another function is called or something else causes the pile of plates to grow as high as the point where your string was, it will overwrite whatever was at that memory location. Once a plate is taken away from the stack, you should never try referencing it again.

What I wouldn't give for a whiteboard.

Why in the hell are you people helping this person? They have blatently stated that they "don't have the time to read how to use code tags". Yet, they had enough time to post multiple posts containing code, in hopes that YOU will take the time to read their unformatted crap, and fix their problem.

Here's a better idea: When people are too lazy to use code tags, EVERYONE that reads their post mark them down. Support the "Big red squares for stupid people." initiative.

Quzah.