Returning local array

[laconstantine]

Hi Everyone,

I have the following function,

char* sample1()
{
char *p = "Israel";
return(p);
}

//in this case the memory storing india is not destroyed at the end
of the function, indicating that it wasn't stored in the stack meant
for the function call.

However, the following function causes unexpected behavior as
expected ;-)

char* sample2()
{
char p[] = "Israel";
return(p);
}

Is it because that the value that in the address that returned by sample2 is still the same i mean its not magicly reseted to zero?

This is c++, why aren't you using std::strings for starters?

[Narue]

>char *p = "india";
This is a pointer to a string literal. When you return p, you're returning the address of the string literal. A string literal has a lifetime beyond the function, so the memory isn't reclaimed and you don't get garbage. This is perfectly legal.

>char p[] = "india";
This is a string literal copied into an array. When you return p, you're returning the address of a local variable. A local variable is destroyed when the function returns, so you get garbage. This results in undefined behavior.

[laconstantine]

when you say garbage you mean the values that is in the memory location that returned in second example?

[Narue]

Yes.

[~s.o.s~]

>char *p = "india"; p here points to literal. It is more like const char* p = "india" . Here it is const data, non-const pointer. Hence you can do something like ++p , --p and get away with it, while trying to manipulate the value won't work. > char[] p = "india" p here is a constant pointer pointing to a non-constant data. Here it is non-const data and constant pointer. Hence you can do something like p[0] = 't' but trying to do ++p or --p won't work.

[laconstantine]

Yes.

So if i do this

char* sample2()
{
char p[] = "Israel";
return(p);
}

the return value is an address of some memory block (garbage).
But now its about the compiler:
Some compilers can leave this values and they still will be the same(Its with VC++ 2005)
And when we will try to use it the values still will be "Israel".

And some compilers are reseting the values to NULL and when we are trying to use it we are geting NULL values.

Yes?

If its yes i have no more questions.
And sorry about me and my questions.

So is it correct??

[Narue]

>Yes?
No. Undefined behavior doesn't mean the values will stay the same or be nulled out. It means that the values could become anything at any time after execution leaves the function. Just because your compiler didn't use the memory immediately doesn't mean the same thing will happen on another run, even with the same compiler.

[laconstantine]

Your compiler didnt use the memory immediately

What do you mean?

You mean that this memory that returned can be used with other program variables or over variables from my program, becuase the function end and the objects are destroyed?

there is no other way the compiler can just magicly use this memory.

[Narue]

I mean that when you create a local variable, the memory for it is reserved to that variable. When you destroy that local variable, the compiler can use that memory for anything it wants. Basically, the memory is no longer yours to access.

[laconstantine]

The compiler can use that memory for anything
it wants.

You mean to reserve memory for new variables and anything else?
yup?

[Narue]

Yes.

[laconstantine]

But the values in this memory location still will be the same until some variable will take this place and change them right?

[Narue]

>But the values in this memory location still will be the same until some
>variable will take this place and change them right?
When memory for a variable is released, you can't use it. At all. End of story. Anything else is simply bad programming practice.

[laconstantine]

I'm not going to use it anyway.
I just asking:
When the object is destroyed the value at the memory location where he been is still the same as it was when the object destroyed, until another object will take this memory place and change its value.

Yes?

[Narue]

You keep asking these questions and the answer is always the same: It's compiler specific.