What REALLY happens when you don't free after malloc?
This has been something that has bothered me for ages now.We are all taught in school (at least, I was) that you MUST free every pointer that is allocated. I'm a bit curious, though, about the real cost of not freeing memory. In some obvious cases, like when `malloc` is called inside a loop or part of a thread execution, it's very important to free so there are no memory leaks. But consider the following two examples:First, if I have code that's something like this: int main() { char *a = malloc(1024); /* Do some arbitrary stuff with 'a' (no alloc functions) */ return 0; }What's the real result here? My thinking is that the process dies and then the heap space is gone anyway so there's no harm in missing the call to `free` (however, I do recognize the importance of having it anyway for closure, maintainability, and good practice). Am I right in this thinking?Second, let's say I have a program that acts a bit like a shell. Users can declare variables like `aaa = 123` and those are stored in some dynamic data structure for later use. Clearly, it seems obvious that you'd use some solution that will calls some *alloc function (hashmap, linked list, something like that). For this kind of program, it doesn't make sense to ever free after calling `malloc` because these variables must be present at all times during the program's execution and there's no good way (that I can see) to implement this with statically allocated space. Is it bad design to have a bunch of memory that's allocated but only freed as part of the process ending? If so, what's the alternative?
You can get away without explicitly freeing space if the sizes are relatively small, the program execution time is relatively short and the program ends normally. However, what about a program such as a listener that runs in the background for a long time? Even small chunks of storage can add up and become a problem.
