«

Hi Everyone,

I have the following function,

char* sample1()
{
char *p = "india";
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[] = "india";
return(p);
}

I tried both the functions in Microsoft Visual C++ 6.0, is it
specified as per the standard that the first case be not stored in the
stack or is it implementation defined?

Thanks in advance!!!

In article <. com>,
<> wrote:

> I have the following function,

> char* sample1()
> {
> char *p = "india";
> 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[] = "india";
> return(p);
>}

> I tried both the functions in Microsoft Visual C++ 6.0, is it
>specified as per the standard that the first case be not stored in the
>stack or is it implementation defined?

In the first case, you are setting the local variable p to point
to the string literal "india". The C standard says that all
string literals will live throughout the execution of the program.
String literals are allowed to be read-only.

In the second case, although the syntax looks so close, you are
instead setting a local variable to point to some automatic
storage space that is initialized to {'i','n','d','i','a',0} .
This is not a string literal, and the space reserved is not
read-only.

Note, by the way, that the C standard says nothing about stacks;
there are implementations that don't use stacks as you know them.
The C standard talks of automatic storage and of variable lifetimes,
without saying how exactly these things are achieved.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

wrote On 05/04/07 16:29,:
> Hi Everyone,
>
> I have the following function,
>
> char* sample1()
> {
> char *p = "india";
> 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.

Correct. The nameless array holding the characters
of "india" has what is called "static storage duration,"
just like variables declared with the `static' keyword.
All static objects already exist and have been initialized
when main() is first called, and continue to exist until
the program ends.

> However, the following function causes unexpected behavior as
> expected

"Expect the unexpected." Difficult advice to follow,
and probably not the best advice for programmers. They
would do better to "Avoid the unexpected."

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

This is perfectly legal! There is, however, one tiny
gotcha: Undefined behavior occurs if the caller makes any
use whatever of the value returned by sample2(). Trying
to call `puts(sample2()()' is obviously off limits, but so
are seemingly harmless uses like `ptr = sample2()' and
`if (sample2() == NULL)'. Only `(void)sample2()' (or an
equivalent) is safe.

Details: The array p[] has "automatic storage duration,"
which lasts from the moment execution enters its block to
the moment execution exits the block. As soon as the block
that is the body of sample2() exits -- at the `return' --
the array p[] ceases to exist, and any pointer that formerly
pointed to any element of p[] has an indeterminate value.
Using an indeterminate value causes undefined behavior.

> I tried both the functions in Microsoft Visual C++ 6.0, is it
> specified as per the standard that the first case be not stored in the
> stack or is it implementation defined?

The implementation decides where to store "india" and
p[]; the Standard has nothing to say about it (the Standard
doesn't even mention "the stack"). Instead, the Standard
specifies the required lifetimes of the various kinds of
objects. The implementation must arrange for the correct
lifetimes, but can do so in any way it pleases.

--

(Walter Roberson) writes:
> In article <. com>,
> <> wrote:
>
>> I have the following function,
>
>> char* sample1()
>> {
>> char *p = "india";
>> 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[] = "india";
>> return(p);
>>}
>
>> I tried both the functions in Microsoft Visual C++ 6.0, is it
>>specified as per the standard that the first case be not stored in the
>>stack or is it implementation defined?
>
> In the first case, you are setting the local variable p to point
> to the string literal "india". The C standard says that all
> string literals will live throughout the execution of the program.
> String literals are allowed to be read-only.
>
> In the second case, although the syntax looks so close, you are
> instead setting a local variable to point to some automatic
> storage space that is initialized to {'i','n','d','i','a',0} .
> This is not a string literal, and the space reserved is not
> read-only.

A quibble: the local variable in sample2(), named "p", doesn't point
to anything. It's an array, not a pointer. (When the name of the
array is used in the return statement, it's implicitly converted to a
pointer value.)

> Note, by the way, that the C standard says nothing about stacks;
> there are implementations that don't use stacks as you know them.
> The C standard talks of automatic storage and of variable lifetimes,
> without saying how exactly these things are achieved.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"