2

I read this: http://www.drpaulcarter.com/cs/common-c-errors.php#2.8 and there's a block of code like that:

#include <string.h>
#include <stdlib.h>
int main()
{
  char *st = malloc(20);   /* st points to allocated array*/

  strcpy(st, "abc");  /* st points to char array */
  free(st);                /* don't forget to deallocate when done! */
  return 0;
}
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
Hieu Nguyen
  • 1,497
  • 3
  • 12
  • 15

6 Answers6

5

On most sane operating systems you don't really have to clean up on exit - it's just a good habit.

The code is just a simplified example of allocating and freeing memory, in a real program you would keep track of memory that needed freeing while the program was running otherwise you would run out of memory (or more likely address space)

Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • 3
    If your code is going to be used in a constantly-running service, you have to be careful to clean up at all times. Otherwise, you run out of memory. If you're only concerned about clean up "on exit," then you probably don't need to worry about it. – Heath Hunnicutt Jun 01 '11 at 17:48
  • Two important points to note: One is that, for very short lived processes that will be called many times, it might actually be more efficient to not clean up memory before you exit if the OS is going to clean it up for you anyway. Also, even if the OS does clean up your memory for you when the program exits, not explicitly freeing it can lead to a lot of noise if you are using tools like valgrind. I find the best practice is to always free everything, and then if you can prove it's actually going to buy you necessary performance later remove the deallocations. – Cercerilla Jun 02 '11 at 01:52
  • Its never OK to do bad things just because you get away with it in that particular situation. You form bad habits, it creates problems for maintainers in the future (the psychopathic ones who know where you live), and as already stated, you cannot use tools to tell you when you have really screwed up. – mattnz Jun 02 '11 at 02:13
  • 1
    @mattnz well, cleaning up something that the OS can clean up far quicker than you is doing something bad. It's not that you "get away with it"; it's a guarantee the OS provides to you. Why not make use of it! – Roman Starkov Feb 03 '12 at 13:14
  • @romkyns : What happens if your code is used in in a process that does not terminate, the OS cannot clean up for you? What if some developer later on reuses you widget in a system service. Theres so much thats out of you control you can rarely safely say "It's OK, the OS will do it". – mattnz Feb 06 '12 at 09:32
  • 1
    @mattnz well duh, then you clean up :) _If_ your process is about to terminate _then_ you are wasting time by cleaning up. In all other cases it is, of course, a necessity. If someone reuses my process in a system service then its behaviour does not change: it will still have all of its memory cleaned up no sooner and no later than its termination point. – Roman Starkov Feb 06 '12 at 15:57
3

You have to deallocate it (via free()) because you allocated it (via malloc()). In most C APIs, generally you are responsible for freeing a pointer if you allocate it. There are some cases in which this isn't true, but the function's man page will usually specify that.

mipadi
  • 398,885
  • 90
  • 523
  • 479
3

The effects of allocating and deallocating memory. Once you allocate memory for some purpose, it stays allocated until you deallocate it. While it's allocated, it is not available for other purposes. The reason to deallocate it is to make that memory available for other uses.

Why this matters. This becomes important if your program continues to allocate new chunks of memory over time. If you don't deallocate memory when you no longer need it, your program's use of memory grows and grows and grows, and may eventually exhaust the pool of memory that the operating system makes available to it.

No real harm in this example. In the particular example you, there's (likely) no harm in skipping the deallocation. For one thing, the program ends immediately thereafter, so the program has no further uses for that memory. For another thing, as others have mentioned, in typical implementations of C, your program gives back all of its memory when it exits.

But if your program might need the memory for something else, or if your program won't give the memory back to the operating system when it exits, it's a good idea to deallocate memory when you no longer need it.

The memory, not the pointer, is deallocated. Strictly speaking, that example does not deallocate the pointer. It deallocates the memory that the pointer points to. The pointer is still there, and in fact is still pointing to the now-deallocated memory. This can lead to endless debugging joy if you inadvertently continue to use the pointer as if it still pointed to memory it owns.

Dale Emery
  • 10,161
  • 1
  • 15
  • 14
2

There is no guarantee that the allocated memory will go back to the system's resources just because the process terminated.

Otávio Décio
  • 73,752
  • 17
  • 161
  • 228
  • 1
    Most modern operating systems, however, make quite an effort to do so though. – Thorbjørn Ravn Andersen Jun 01 '11 at 19:04
  • This is, in fact, a guarantee provided by Windows: all resources of a terminated process are properly reclaimed. Whether any bugs prevent this from happening is a separate question, but in practice, such bugs are between rare and non-existent. – Roman Starkov Feb 03 '12 at 13:18
1

In the main() function, once the program exits, all of the memory allocated is returned back to the OS even if you don't deallocate it explicitly. So doing it manually is generally known as a good practice, this "good practice" has real implications. If you were to have this code in another function or even inside main and with in a loop, your program would allocate and deallocate the memory as per code. If you had the code in a loop and with no deallocations, this would eventually eat all your memory, causing your program to crash unless handled. In certain conditions this is called a memory leak. So, know the good practices well! Memory Leak

Wajih
  • 793
  • 3
  • 14
  • 31
  • 1
    This is only true if the operating system deallocates the memory when the process exits. For historical contrast, consider both MacOS 9.x and prior as well as 16-bit Windows with its LocalAlloc() API. – Heath Hunnicutt Jun 01 '11 at 17:48
  • @Heath: I don't remember that about MacOS 9 and earlier, and I did quite a bit of C programming on my Macs. I don't think I was that good at memory management (I'm not sure I am now). – David Thornley Jun 01 '11 at 18:15
  • @David: I have no experience coding for MacOS, just hearsay. – Heath Hunnicutt Jun 01 '11 at 18:20
1

Otherwise the C memory allocator does not know that you are done using it.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347