Why is it the program responsibility to deallocate dynamic memory allocation?

[Absurd]

I hope this is the right place to ask this question, I just couldn't find any suitable place. I tried to answer this to myself but couldn't.

Why isn't dynamic memory (allocated on the heap) automatically deallocated by the operating system?
Why is it the process responsibility to do it?
If a program does something stupid like that:

int main() {
     malloc(20);
     return 0;
}

These are 20 bytes that are not gonna be accessible by anyone, not even the parent-process that have created the process running this code.
If it is a shared memory allocation, then there is a solid argument in favor of keeping it persist in memory even after the process creating it has ended, and you can in fact access it later through the OS API (the <sys/shm.h> library, if I remember correctly, provides this functionality), but I can't find any good reason for when it is not a shared memory. And it's not like the OS can't tell the difference between a shared memory allocation and a 'local' memory allocation - since its API provides different functions to do it.

[Elkvis]

Your sample program is a bad example, because when the program exits, the operating system reclaims any unshared memory allocated to it. The problem comes when the program continues, but does not free memory that it has allocated, but no longer uses.

[Salem]

> Why isn't dynamic memory (allocated on the heap) automatically deallocated by the operating system?
Where did you read that?
It certainly isn't true of modern operating systems which place each process into a virtual address space.

It might be true for archaic DOS, and some kinds of simple RTOS.

[Absurd]

>Your sample program is a bad example, because when the program exits, the operating system reclaims any unshared memory allocated to it.

>Where did you read that?

Doesn't calling malloc without a corresponding free (on the pointer returned by malloc) cause a memory leak?

[Elkvis]

>Where did you read that?

Doesn't calling malloc without a corresponding free (on the pointer returned by malloc) cause a memory leak?

Yes, but only within the context of the process that called malloc. When the program ends, that memory is automatically freed by the operating system.

[grumpy]

With a number of modern operating systems (windows, unix, etc) dynamically allocated memory IS released (or, more accurately, recovered) by the operating system as the program terminates.

The catch is that the operating system has to be specifically designed so it can do that - that sort of thing is generally not something that hardware can do on its own (unless it is power cycled, and sometimes not even then). A number of older operating systems (including older variants of windows) were not designed with that in mind. Programs that run without an operating system also clearly cannot rely on the operating system cleaning up after them.

The more common reason for the recommendation that programmers deallocate memory they allocate is to allow code reuse. One technique, for example, is to rename a program's main() function, recompile, and call that (renamed) function from other code. If the program being reused does not clean up properly after itself (i.e. it leaks memory) then it can compromise behaviour of the program in which it is reused - particularly if the new program calls the offending code repeatedly, or if it runs for a long time after calling the offending function. There is no way that an operating system can sensibly correct for that.

[Absurd]

Yes, but only within the context of the process that called malloc. When the program ends, that memory is automatically freed by the operating system.

Wow, OK... because up until now, when I read 'memory leak' I understood that it means that the memory leaks after the program has terminated, not during its running time.
Thanks.

[Elysia]

Also consider cleanup. In C, sometimes structs are used as "objects," meaning they're initialized and then destructed when freed by calling an initialize function and destruct function, respectively. If you just ignore destructing some constructed "object," then you might not clean up properly. So the advice is always clean up what you allocate even if it's just raw memory.

[jjohan]

Question from a beginner who just read about malloc() today:
If we should free memory when using malloc(), shouldn't we free memory for normal variables when we are done using them?
What I mean is for example:

...a lot of code here...
a for loop using the variable i
... a lot of code here, not using the variable i.....

Shouldn't we free the memory used by the variable i after the for loop here?
It's no longer used so its' memory should be returned?

[Elysia]

Stack variables are automatically freed (when the current scope or function ends). Memory allocated from malloc is not (hence the need for explicit free).

[jjohan]

Oh ok, thanks Elysia. But, memory allocated with malloc is also freed when the program ends (by the OS)?

[Elysia]

Yes, but it is not freed while the program is running (unlike stack variables).

[jjohan]

OK, thanks again

[Click_here]

I think that I should add that C is not an OS implementation, it is a language.

Most of the C programs I write do not run on an operating system at all - There is NO operating system to free all the memory

[PaulS]

I think that I should add that C is not an OS implementation, it is a language.

Most of the C programs I write do not run on an operating system at all - There is NO operating system to free all the memory

Could you elaborate on that statement? How does a C program run independent of an operating system unless the program is the operating system?