Automatic variable is not destroyed?

[loudking]

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
char *c= "Automatic";

return c;
}

int main(int argc, char*argv[])
{
char *c= GetChar();

printf("c=%c\n", *c);

return 0;
}

I think variable c in GetChar is an automatic variable, and it should
be destroyed immediatly after the function is called. Then the array
that c is pointing to should be freed as well - GetChar is not
mallocing any address.

Could anybody explain why the caller (main) is still reaching the
correct address, please?

 

[Nick Keighley]

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
        char *c= "Automatic";
        return c;
}

int main(int argc, char*argv[])
{
        char *c= GetChar();
        printf("c=%c\n", *c);
        return 0;
}

I think variable c in GetChar is an automatic variable,
yes

and it should
be destroyed immediatly after the function is called.

no. It goes out of scope. c can no longer be accessed
but on many implementations the memory used by c still
exists. For instance it is common to use a stack to
store automatic variables.

Then the array
that c is pointing to should be freed as well

no. c goes out of scope, it is not "freed", that is free()
is not called. The string "Automatic" is a static string
and its lifetime is as long as the program. static
strings are never "freed".

- GetChar is not mallocing any address.

yes. Why on eartn should it, it never calls malloc()!

Could anybody explain why the caller (main) is still reaching the
correct address, please?

Yes c goes out of scope but the value of c is returned
by the function and the value of c is the address of (pointer to)
a static array. This is ok.

Consider value return. Do you expect this to give problems?

int getInt (void)
{
int i = 3;
return i;
}

because you shouldn't.

Where you can go wrong is with returning addresses of things that
don't exist

char *getCharPtr(void)
{
char c = 'a';
return &c;
}

int main(void)
{
printf ("%c\n", *getCharPtr()); /* BAD!! */
return 0;
}

or

char *getStr()
{
char myStr[] = "Automatic";
return myStr;
}

this is *not* the same your example as memory is set aside
for the characters in myStr, it is initialised with the values in
"Automatic", and all teh memory used by myStr goes away when you
exit for getStr(). The static string "Automatic" still exists
(as before) but myStr isn't pointing at it.

 

[Richard Tobin]

char *getStr()
{
char myStr[] = "Automatic";
return myStr;
}

this is *not* the same your example as memory is set aside
for the characters in myStr, it is initialised with the values in
"Automatic", and all teh memory used by myStr goes away when you
exit for getStr(). The static string "Automatic" still exists
(as before) but myStr isn't pointing at it.

I don't think there is any requirement for a static string to exist
here. In practice it probably does, but a compiler is free to
initialise myStr using any method that puts the right characters
in it.

Also, myStr never *points at* a static string; the characters are
copied into it.

-- Richard

 

[Chris Dollin]

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
char *c= "Automatic";

return c;
}

int main(int argc, char*argv[])
{
char *c= GetChar();

printf("c=%c\n", *c);

return 0;
}

I think variable c in GetChar is an automatic variable, and it should
be destroyed immediatly after the function is called.

That's right. `c` evaporates when `GetChar` returns. However, its
value does not. That value is a pointer to (the first element of) a
static array containing 'A', 'u', 't', 'o', 'm', 'a', 't', 'i', 'c',
0.

Then the array
that c is pointing to should be freed as well

No, it should not.

- GetChar is not mallocing any address.

Correct.

--
"We did not have time to find out everything /A Clash of Cymbals/
we wanted to know." - James Blish

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 

[Nick Keighley]

char *getStr()
{
    char myStr[] = "Automatic";
    return myStr;
}

this is *not* the same your example as memory is set aside
for the characters in myStr, it is initialised with the values in
"Automatic", and all teh memory used by myStr goes away when you
exit for getStr(). The static string "Automatic" still exists
(as before) but myStr isn't pointing at it.

I don't think there is any requirement for a static string to exist
here.  

syntactically there's a static string present. Though by the asif
rule it never needs to exist past <some> translation phase.

I was trying to ignore AS-IF

In practice it probably does, but a compiler is free to
initialise myStr using any method that puts the right characters
in it.
yes

Also, myStr never *points at* a static string; the characters are
copied into it.

my intent was to make that clear. myStr *never* points at
"Automatic" but is initialised with its contents. I agree
this
<<The static string "Automatic" still exists (as before)
but myStr isn't pointing at it.>>

isn't as clear as it might have been

 

[Andrey Tarasevich]

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
char *c= "Automatic";

return c;
}

int main(int argc, char*argv[])
{
char *c= GetChar();

printf("c=%c\n", *c);

return 0;
}

I think variable c in GetChar is an automatic variable,
Correct.

and it should
be destroyed immediatly after the function is called.
Yes.

Then the array
that c is pointing to should be freed as well
> GetChar is not mallocing any address.

No. String literals are arrays with static storage duration in C. They
live "forever", i.e as long as the program is running.

Could anybody explain why the caller (main) is still reaching the
correct address, please?

Firstly, see above.

Secondly, things like that are cannot be in general verified by an
experimental program. Just because some program seems to be displaying
the expected contents of some object, does not mean that this object is
still alive. In this case it indeed is, but in general experiments like
this one might produce the "expected" output even though the object
itself is long dead and its memory has been deallocated. The deallocated
memory might still be accessible and it might still hold the former
value, thus creating the illusion that the object is still alive. What
I'm trying to say here is that .

 

[Keith Thompson]

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
char *c= "Automatic";
return c;
}

int main(int argc, char*argv[])
{
char *c= GetChar();
printf("c=%c\n", *c);
return 0;
}

I think variable c in GetChar is an automatic variable, yes

and it should
be destroyed immediatly after the function is called.

no. It goes out of scope. c can no longer be accessed
but on many implementations the memory used by c still
exists. For instance it is common to use a stack to
store automatic variables.

No. c is destroyed.
If the function were to be changed
so that it would return the value of the address of c,
then that return value would be indeterminate.

The address of an out of scope variable, has no problems like that.

I think what Nick meant is that, even though c has gone out of scope,
it's likely (but by no means guaranteed) that the memory still exists
and still contains a pointer to the string literal. c no longer
exists as far as the C standard is concerned, but it's not "destroyed"
(depending on just what you mean by "destroyed"). An implementation
is not required to, and a typical implementation does not, prevent you
from attempting to access it, and such an attempt may appear to
succeed.

As a programmer, you should certainly assume that c no longer exists
(in the sense that you shouldn't attempt to access it), but it's
entirely up to you to enforce that assumption.

 

[gw7rib]

Hello all, please take a look at following code:
#include <stdio.h>
#include <stdlib.h>
char* GetChar()
{
        char *c= "Automatic";
        return c;
}
int main(int argc, char*argv[])
{
        char *c= GetChar();
        printf("c=%c\n", *c);
        return 0;
}
I think variable c in GetChar is an automatic variable,
yes
and it should
be destroyed immediatly after the function is called.
no. It goes out of scope. c can no longer be accessed
but on many implementations the memory used by c still
exists. For instance it is common to use a stack to
store automatic variables.

No. c is destroyed.
If the function were to be changed
so that it would return the value of the address of c,
then that return value would be indeterminate.

The address of an out of scope variable, has no problems like that.

I think what Nick meant is that, even though c has gone out of scope,
it's likely (but by no means guaranteed) that the memory still exists
and still contains a pointer to the string literal.  c no longer
exists as far as the C standard is concerned, but it's not "destroyed"
(depending on just what you mean by "destroyed").  An implementation
is not required to, and a typical implementation does not, prevent you
from attempting to access it, and such an attempt may appear to
succeed.

As a programmer, you should certainly assume that c no longer exists
(in the sense that you shouldn't attempt to access it), but it's
entirely up to you to enforce that assumption.

I think what Pete is trying to say here - even if not, it's the point
I want to make - is that you and Nick each seem to be using the phrase
"goes out of scope" wrongly. As I understand it, the scope of a
variable is the bits of a program in which it can be accessed by that
name.

For instance, in the prgram above, c is/may be/is liable to be
destroyed when GetChar finishes. If it were made a static varibale, it
would not be destroyed and would hang around. But under either case,
the name c would go out of scope at the end of GetChar, in the sense
that the bit of program now executing couldn't refer to c by name.

 

[Keith Thompson]

Nick Keighley wrote:
On 24 Nov, 10:54, loudking <[email protected]> wrote:

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
        char *c= "Automatic";
        return c;
}

int main(int argc, char*argv[])
{
        char *c= GetChar();
        printf("c=%c\n", *c);
        return 0;
}

[snip]
I think what Pete is trying to say here - even if not, it's the point
I want to make - is that you and Nick each seem to be using the phrase
"goes out of scope" wrongly. As I understand it, the scope of a
variable is the bits of a program in which it can be accessed by that
name.

Quite correct. It's c's lifetime that ends at that point, not just
its scope. If c were static, its scope end end on return from
GetChar(), but its lifetime wouldn't.

 

[jameskuyper]

Nick Keighley wrote:
On 24 Nov, 10:54, loudking <[email protected]> wrote:

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
� � � � char *c= "Automatic";
� � � � return c;
}

int main(int argc, char*argv[])
{
� � � � char *c= GetChar();
� � � � printf("c=%c\n", *c);
� � � � return 0;
}

I think variable c in GetChar is an automatic variable,
yes

and it should
be destroyed immediatly after the function is called.
no. It goes out of scope. c can no longer be accessed
but on many implementations the memory used by c still
exists. For instance it is common to use a stack to
store automatic variables.

No. c is destroyed.
If the function were to be changed
so that it would return the value of the address of c,
then that return value would be indeterminate.

The address of an out of scope variable, has no problems like that.

I think what Nick meant is that, even though c has gone out of scope,
it's likely (but by no means guaranteed) that the memory still exists
and still contains a pointer to the string literal. �c no longer
exists as far as the C standard is concerned, but it's not "destroyed"
(depending on just what you mean by "destroyed"). �An implementation
is not required to, and a typical implementation does not, prevent you
from attempting to access it, and such an attempt may appear to
succeed.

As a programmer, you should certainly assume that c no longer exists
(in the sense that you shouldn't attempt to access it), but it's
entirely up to you to enforce that assumption.

I think what Pete is trying to say here - even if not, it's the point
I want to make - is that you and Nick each seem to be using the phrase
"goes out of scope" wrongly. ...

I don't believe that this is the case. Reviewing their statements
cited above, I can find no incorrect use of that phrase.

... As I understand it, the scope of a
variable is the bits of a program in which it can be accessed by that
name.

That's how the standard defines the term. It then goes on to specify
that two declarations of the same identifier can have overlapping
scopes, and that the identifier in the outer scope is hidden by the
declaration in the inner scope. From the definition, that implies that
the inner scope is not part of the outer scope; in which case, in what
sense do they overlap? Therefore, the definition is a little unclear.
But I think I know what the intended meaning is.

For instance, in the prgram above, c is/may be/is liable to be
destroyed when GetChar finishes.

No, 'c's lifetime ends at that point. However, the standard says
nothing about destruction of the object at the end of its lifetime. It
doesn't even indicate what the word "destroy" might mean in this
context. The standard certainly doesn't mandate any change to the
contents of an object when the object's lifetime ends, and that is
what Keith was pointing out.

 

[Keith Thompson]

Nick Keighley wrote:

Hello all, please take a look at following code:

#include <stdio.h>
#include <stdlib.h>

char* GetChar()
{
� � � � char *c= "Automatic";
� � � � return c;
}

int main(int argc, char*argv[])
{
� � � � char *c= GetChar();
� � � � printf("c=%c\n", *c);
� � � � return 0;
}

I think variable c in GetChar is an automatic variable,
yes

and it should
be destroyed immediatly after the function is called.
no. It goes out of scope. c can no longer be accessed
but on many implementations the memory used by c still
exists. For instance it is common to use a stack to
store automatic variables.

No. c is destroyed.
If the function were to be changed
so that it would return the value of the address of c,
then that return value would be indeterminate.

The address of an out of scope variable, has no problems like that.

I think what Nick meant is that, even though c has gone out of scope,
it's likely (but by no means guaranteed) that the memory still exists
and still contains a pointer to the string literal. �c no longer
exists as far as the C standard is concerned, but it's not "destroyed"
(depending on just what you mean by "destroyed"). �An implementation
is not required to, and a typical implementation does not, prevent you
from attempting to access it, and such an attempt may appear to
succeed.

As a programmer, you should certainly assume that c no longer exists
(in the sense that you shouldn't attempt to access it), but it's
entirely up to you to enforce that assumption.

I think what Pete is trying to say here - even if not, it's the point
I want to make - is that you and Nick each seem to be using the phrase
"goes out of scope" wrongly. ...

I don't believe that this is the case. Reviewing their statements
cited above, I can find no incorrect use of that phrase.

Perhaps, but I think the end of c's lifetime was more relevant here
than the end of its scope, even though they both occur at the same
place. (That's a little misleading; scope is a region of program
text, while lifetime is a span of execution time.)

[...]

No, 'c's lifetime ends at that point. However, the standard says
nothing about destruction of the object at the end of its lifetime. It
doesn't even indicate what the word "destroy" might mean in this
context. The standard certainly doesn't mandate any change to the
contents of an object when the object's lifetime ends, and that is
what Keith was pointing out.

Which is why the previous poster said that c "is/may be/is liable to
be destroyed when GetChar finishes", which IMHO is weaselly enough to
be correct.