c - When a program terminates what happens to the memory allocated using malloc that is not free'ed?

Question

Say I have the following program

#include <stdio.h>
#include <stdlib.h>

int main(void) 
{
    int * i;

    if ((i = malloc(sizeof(int) * 100)) == NULL) {
        printf("EROOR: unable to allocate memory 
");
        return -1;
    }

    /* memory is allocated successfully */

    /* memory is not free'ed but program terminates */
    // free(i);

    return 0;
}

The above program calls malloc to allocate some memory and does not call free to de-allocate it. And the program terminates without de-allocating the memory.

Valgrind clearly detects a memory leak.

<snap>
==14209== HEAP SUMMARY:
==14209==     in use at exit: 400 bytes in 1 blocks
==14209==   total heap usage: 1 allocs, 0 frees, 400 bytes allocated
==14209== 
<sanp>
==14209== LEAK SUMMARY:
==14209==    definitely lost: 400 bytes in 1 blocks
==14209==    indirectly lost: 0 bytes in 0 blocks
==14209==      possibly lost: 0 bytes in 0 blocks
==14209==    still reachable: 0 bytes in 0 blocks
==14209==         suppressed: 0 bytes in 0 blocks
==14209== 
==14209== For counts of detected and suppressed errors, rerun with: -v
==14209== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Question:

When the program terminates, what happens to the memory that was allocated but not free'd?

Update: Consider that this code is being executed on different operation system - say windows, linux, solarix, macos, etc. Is there any difference in the behavior of this code during its termination?

Answer 1

The other answers tell you the two important things:

1. Yes, the memory is reclaimed by the OS, so you don't technically need to free() it.
2. It's good practice to free everything you malloced anyway.

However, it's important to say why it's good practice to free() everything you've malloced. In my view:

1. Habit: If you get in the habit of freeing whenever you've malloced, you won't accidentally forget when a memory segment isn't around for the lifetime of the program.
2. Maintainability: If someone comes along to refactor your program so that a segment of memory is no longer around for the lifetime of the program, the presence of cleanup code in the original will mean that it's very likely that the refactored version also includes the cleanup code. For me, this is the most important reason.
3. Debugging: If we expect that all memory is cleaned up correctly, then spotting memory that's actually leaking is much easier.