Like Tree2Likes
  • 1 Post By manasij7479
  • 1 Post By Adak

Freeying Memory

This is a discussion on Freeying Memory within the C Programming forums, part of the General Programming Boards category; Do we need to free memory allocated by malloc inside user defined function? isn't that automatically freed when the function ...

  1. #1
    Registered User
    Join Date
    Feb 2012
    Location
    Bangalore, India
    Posts
    12

    Freeying Memory

    Do we need to free memory allocated by malloc inside user defined function? isn't that automatically freed when the function returns? suppose if we free using fee(), does it have any affect (need not be reflected in output)?

  2. #2
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by durgadatta View Post
    Do we need to free memory allocated by malloc inside user defined function?
    No, not if you return a reference to the memory so that you can free it later on when you are done.

    Quote Originally Posted by durgadatta View Post
    isn't that automatically freed when the function returns?
    No

    Quote Originally Posted by durgadatta View Post
    suppose if we free using fee(), does it have any affect (need not be reflected in output)?
    It does if you are trying to use the free'd item after, you would use free when you don't need the object anymore.

  3. #3
    Registered User
    Join Date
    Feb 2012
    Location
    Bangalore, India
    Posts
    12
    but the memory occupied by other variables declared locally inside the user defined function can be used for other purpose once the funcion is returned. Doesnot this happen to allocated memory too which is a pointer type variable. After the function returns, cant the memory pointed by the pointer used as a free memory for new memory allocation and variables.

  4. #4
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Quote Originally Posted by durgadatta View Post
    but the memory occupied by other variables declared locally inside the user defined function can be used for other purpose once the funcion is returned. Doesnot this happen to allocated memory too which is a pointer type variable. After the function returns, cant the memory pointed by the pointer used as a free memory for new memory allocation and variables.
    If you malloc the memory inside the function and not free it, it can be used after the call returns .
    But if it is a local variable declared on the stack, using pointers returned from a function gives undefined behaviour.
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  5. #5
    Registered User
    Join Date
    Feb 2012
    Location
    Bangalore, India
    Posts
    12
    Quote Originally Posted by manasij7479 View Post
    If you malloc the memory inside the function and not free it, it can be used after the call returns .
    But if it is a local variable declared on the stack, using pointers returned from a function gives undefined behaviour.
    so does it not mean that its absolutely not necesarry to use free() if we malloc inside user defined function? Subsonics on first reply said tat we nee not free IF (only) we return reference to free later.

  6. #6
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Quote Originally Posted by durgadatta View Post
    so does it not mean that its absolutely not necesarry to use free() if we malloc inside user defined function? Subsonics on first reply said tat we nee not free IF (only) we return reference to free later.
    If you do not use free inside the function and return a pointer, you must free that pointer later on after it is used....otherwise it is a memory leak.
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  7. #7
    Registered User
    Join Date
    Feb 2012
    Location
    Bangalore, India
    Posts
    12
    I think if we return a pointer to the meory allocated in user defined function we cant access it form outside sicne the scope of memory allocated inisde function is local. is it not so?

  8. #8
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Quote Originally Posted by durgadatta View Post
    I think if we return a pointer to the meory allocated in user defined function we cant access it form outside sicne the scope of memory allocated inisde function is local. is it not so?
    No you're wrong.
    As the memory is allocated on the heap, it can be accessed after the function returns.
    Adak likes this.
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  9. #9
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    The pointer is valid once malloc'd, even after you leave the function - it is not local (on the heap instead). HOWEVER, if it pointed to a local variable, then that pointer, although perfectly valid, should NOT be used, because what it's pointing to, is no longer valid.

    The funny thing is, those local variables that are no longer valid, are still there on a little used system, for awhile. BUT DON'T COUNT ON IT!!

    That's the Golden Rule of returning addresses - never return the address (pointer), of a local variable.
    manasij7479 likes this.

  10. #10
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Quote Originally Posted by Adak View Post
    The funny thing is, those local variables that are no longer valid, are still there on a little used system, for awhile. BUT DON'T COUNT ON IT!!
    Btw.. what happens to that space? .. surely the OS has better work to do other than clearing out memory just below the stack ?
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  11. #11
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    I don't believe it's RIGHT next to the stack - the OS saves that to detect errors, I believe.

    When I've played with it, the local variables that were not valid anymore, were still there, as long as the system was not busy. Once it got busy, those values were overwritten within a few seconds. On a server like Windows 2008 which I was just testing out last week, it's different though. There, the administrator can set the memory to be "scrubbed" on a few different schedules.

  12. #12
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,832
    The stack does not get cleaned up by the OS. It's a dedicated area of memory for that process. Things don't get overwritten until you enter another function and use more local variables.
    As each process has its own stack area, there is nobody who will use yours.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Dynamic memory and realloc(), freeing memory
    By C_Sparky in forum C Programming
    Replies: 6
    Last Post: 10-06-2010, 08:55 PM
  2. Replies: 12
    Last Post: 04-11-2010, 08:14 AM
  3. Allocate memory inside allocated memory block?
    By Heidi_Nayak in forum C Programming
    Replies: 14
    Last Post: 04-15-2009, 05:19 PM
  4. Finding memory address using memory pattern
    By MindWorX in forum C++ Programming
    Replies: 1
    Last Post: 05-25-2008, 08:20 AM
  5. Replies: 2
    Last Post: 09-28-2006, 02:06 PM

Tags for this Thread


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