Automatic variable is not destroyed?

Discussion in 'C Programming' started by loudking, Nov 24, 2008.

  1. loudking

    loudking Guest

    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?
    loudking, Nov 24, 2008
    #1
    1. Advertising

  2. On 24 Nov, 10:54, loudking <> 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.

    > 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.


    --
    Nick Keighley

    "Infinitely many bits doesn't give you "100% accuracy". You will
    only be able to represent the algebraic numbers."
    Nick Keighley, Nov 24, 2008
    #2
    1. Advertising

  3. In article <>,
    Nick Keighley <> wrote:

    >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
    --
    Please remember to mention me / in tapes you leave behind.
    Richard Tobin, Nov 24, 2008
    #3
  4. loudking

    Chris Dollin Guest

    loudking 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, 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
    Chris Dollin, Nov 24, 2008
    #4
  5. On 24 Nov, 11:41, (Richard Tobin) wrote:
    > In article <>,
    > Nick Keighley  <> wrote:


    > >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


    --
    Nick Keighley
    Nick Keighley, Nov 24, 2008
    #5
  6. loudking wrote:
    >
    > #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 .

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Nov 24, 2008
    #6
  7. pete <> writes:
    > Nick Keighley wrote:
    >> On 24 Nov, 10:54, loudking <> 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 24, 2008
    #7
  8. loudking

    Guest

    On 24 Nov, 16:05, Keith Thompson <> wrote:
    > pete <> writes:
    > > Nick Keighley wrote:
    > >> On 24 Nov, 10:54, loudking <> 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. 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.
    , Nov 24, 2008
    #8
  9. writes:
    > On 24 Nov, 16:05, Keith Thompson <> wrote:
    >> pete <> writes:
    >> > Nick Keighley wrote:
    >> >> On 24 Nov, 10:54, loudking <> 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 24, 2008
    #9
  10. loudking

    jameskuyper Guest

    wrote:
    > On 24 Nov, 16:05, Keith Thompson <> wrote:
    > > pete <> writes:
    > > > Nick Keighley wrote:
    > > >> On 24 Nov, 10:54, loudking <> 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.
    jameskuyper, Nov 24, 2008
    #10
  11. jameskuyper <> writes:
    > wrote:
    >> On 24 Nov, 16:05, Keith Thompson <> wrote:
    >> > pete <> writes:
    >> > > Nick Keighley wrote:
    >> > >> On 24 Nov, 10:54, loudking <> 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.)

    [...]

    >> 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.


    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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 24, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Louis.
    Replies:
    1
    Views:
    404
    Gunnar Hjalmarsson
    Dec 18, 2004
  2. Quentin Huo
    Replies:
    6
    Views:
    349
    Kevin Spencer
    Apr 2, 2004
  3. enrique
    Replies:
    8
    Views:
    537
    Kevin McMurtrie
    Apr 29, 2005
  4. Steven T. Hatton
    Replies:
    3
    Views:
    361
    Victor Bazarov
    Mar 7, 2006
  5. joanne

    Excel COM object not being destroyed

    joanne, Oct 22, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    95
    joanne
    Oct 22, 2003
Loading...

Share This Page