Warning : returns address of a local variable YET correct output

This is a discussion on Warning : returns address of a local variable YET correct output within the C Programming forums, part of the General Programming Boards category; This problem was suggested to me by a friend. The code is - Code: /* Returning a pointer to an ...

  1. #1
    Registered User
    Join Date
    Jul 2009
    Posts
    9

    Warning : returns address of a local variable YET correct output

    This problem was suggested to me by a friend.
    The code is -
    Code:
    /* Returning a pointer to an out of scope variable */
    
    # include <stdio.h>
    
    int* fun(){
      int k = 35;
      return &k;
    }
    int main(void){
      int *j;
      j = fun();
      printf("%d",*j);
      return 0;
    }
    Compiling this on GCC gives the above warning because k is a local variable and it will go out of scope once the function returns. Yet, when I run the program I get a perfectly correct output. That is 35. Why is this? Shouldn't I be getting garbage value?

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    35 is a garbage value. The fact that it coincidentally matches the value you want to get is a coincidence.

    EDIT: F'r'instance, what about this:
    Code:
    # include <stdio.h>
    
    int* fun(){
      int k = 35;
      return &k;
    }
    int otherfun(int bob) {
        int x;
        x = 275-bob;
        return x;
    }
    
    int main(void){
      int *j, k;
      k = 6;
      j = fun();
      otherfun(k);
      printf("%d",*j);
      return 0;
    }
    Last edited by tabstop; 08-13-2009 at 07:39 AM.

  3. #3
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    Why is this?
    Because the way memory was handled in this case, happened to work in your favor. But once the variable goes out of scope, you have no guarantee that the space won't be allocated to something else, or changed entirely. It's not that it never works, it's that it's never reliable. It's undefined.

  4. #4
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,831
    Quote Originally Posted by tapti View Post
    Why is this? Shouldn't I be getting garbage value?
    As with most storage systems (memory or disk drive), the less work and effort put towards a pointless activity, the faster it is.

    The value that was in-scope during the function was on the stack. There is no reason the computer should take the time to "clean up", zero out, or otherwise randomize past values residing in memory. The value that was there (the 35) simply continues to reside there until there is a compelling reason to overwrite that same location.

    I would not agree that it's a coincidence as tabstop does. I'd say there's a 100% chance that value will be there given the exact same conditions, compiler, order of code, etc.

    I bet a 1000 byte chunk of memory is still intact after a free() as well... If I claimed it was "coincidence" that all 1000 bytes were exactly the same as before, that would be statistically astronomical and I should buy lottery tickets.

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by nonoob View Post
    I would not agree that it's a coincidence as tabstop does. I'd say there's a 100% chance that value will be there given the exact same conditions, compiler, order of code, etc.
    I don't.

    1. Stack frame of this function is created on the stack such that the variable in question exists precisely on a page boundary.
    2. Function returns.
    3. Program gets scheduled out.
    4. Memory pressure on the system causes swap algorithms to activate.
    5. Stack space below the stack pointer is discardable, so it can be unmapped.
    6. Program gets scheduled back in.
    7. Program tries to access memory below the current stack pointer.
    8. This page is unmapped.
    9. EXPLOSION
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Registered User
    Join Date
    Jul 2009
    Posts
    9
    Thanks, I get it now.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. File Server Help
    By lautarox in forum C Programming
    Replies: 146
    Last Post: 09-24-2008, 06:32 PM
  2. Replies: 2
    Last Post: 07-08-2008, 03:45 AM
  3. I thought pointers were pointers...
    By keira in forum C Programming
    Replies: 19
    Last Post: 08-15-2007, 11:48 PM
  4. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 01:27 PM
  5. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 05:06 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21