It is implementation specific.
On most operating systems (notably desktop or server OSes, e.g. Linux, MacOSX, Windows…) once a process is terminated, every used resources is released, and that includes its virtual address space. Hence even unfreed heap memory is released.
In particular, if you code a quickly running program (e.g. you know that it always will run in less than few seconds), it might be easier to accept some memory leak (but if you do, please comment that in your code and/or documentation). And many real life programs are doing that (in particular the GCC compiler, and probably several Unix shells).
On the contrary, if you are coding a server (e.g. a database or compute server), you should avoid any memory leaks which would make the server’s process RSS grow indefinitely (till some crash). You usually should take great care that every allocated heap memory to deal with one request gets free-d after replying to that request.
On some embedded operating systems, if you don’t release all the resources explicitly (free all heap allocated memory, fclose all opened streams) and properly, you have a resource leak.
See also this related question. On many OSes (including Linux) you can use valgrind to hunt memory leak bugs. With a recent gcc you might use debugging options like -g -fsanitize=address
Read also (at least for the concepts and the terminology) something about garbage collection and about fragmentation. If programming in C, you might consider using Boehm’s garbage collector.
There is however a very good practical reason to systematically free all previously malloc-ed memory: it is a good programming discipline, and it helps a lot using tools like valgrind which helps debugging genuine memory bugs. Also it makes your code more clean, and you could reuse it in some different contexts (e.g. as part of some library, usable in long-running processes).
1
solved Free() before return 0;