Is it necessary to call free function every time we use malloc in C. I am asking this because I have seen many times that it is not called .
Thank you
2
-
3What is your familiarity with memory management? Are these objects ones that live to the end of the program?– user40980Jun 20, 2014 at 14:41
-
Yes it is necessary, otherwise memory is left taking up space on the free store. When you don't see it called it is probably called somewhere you don't expect it to be :)– Richard BamfordNov 22, 2022 at 19:58
Add a comment
|
3 Answers
If the object lives to the end of the program, then you don't need to call free, but I would hold that it is still good practice to do so. The reason here is that, at the end of your code's execution, all of the memory will be free'd anyway, so there's no need to do so explicitly. Otherwise, yes; use free always.
-
Does calling a free function increases its time complexity significantly ?– SupreetJun 20, 2014 at 14:44
-
-
Time complexity certainly won't be significantly affected. Time for shutdown may. In the worst case, swapping lots of memory in just to mark it as no longer in use, walking lots of data structures needlessly, potentially forcing more useful memory to be swapped out, before letting the OS discard it on program end. What a waste of time. Nov 17, 2022 at 22:57
As pointed out in this question, for the particular case of freeing memory immediately before terminating the program, free is a waste of time if your program runs on pretty much any modern operating system. You'll be making the allocator do the work of tracking down the memory and marking it as unused, despite the fact that the OS can free the memory in one fell swoop. As Raymond Chen points out, if the amount of memory to be freed at program exit is large, the time wasted can be significant.
However, this behavior is still OS-dependent. With respect to the language, it is always wrong to not free memory. More importantly, tools like lint or Valgrind will report this as an error, and if you get used to ignoring their errors you defeat the purpose of using them. So I'd treat the practice of not freeing at program exit as an optimization, and you shouldn't optimize prematurely.
If we're not talking about program exit, failing to free is most definitely a bug. No one would intentionally do that if their goal is to write a program that doesn't leak memory.
-
What is a simple program today might become part of a larger program tomorrow, and you might want to start it and close it down, then start it again and close it down again. Then being able to clean up is a suddenly necessary. Nov 20, 2022 at 17:01
Each call to malloc allocates memory on the heap and returns a pointer to it. If you do not call free on the returned pointer, the memory is not freed (so you get a memory leak).
In most trivial cases it is not really necessary to call free (i.e. the application will probably run fine without it), but most people (rightly) consider not freeing the memory a bug.
There are also cases when you allocate memory with malloc and leave it in a static or global variable, relying on the operating system to release this memory when the application finishes running. Normally you shouldn't do this. If you have need of a memory block to remain allocated as long as a library has work to do, consider adding a Finalize/Close/Finish/Uninitialize API to your library that de-allocates this memory (such an API should be called as the last call of your program into your library API).
TLDR: While in most cases it may not be strictly necessary, omitting free-ing the memory is a bug and you (probably) should avoid it (i.e. ensure you always call free for malloc-ed memory).
