c - Does every malloc call have to be freed

Question

From what I understand because malloc dynamically assigns mem , you need to free that mem so that it can be used again.

1. What happens if you return a char* that was created using malloc (i.e. how are you supposed to free that)
2. If you leave the pointer as it is and exit the application will it be freed.(I cant find a definite answer on this , some say yes , some say no).

Answer 1

1. The caller has to free it (or arrange for it to be freed). This means that functions that create and return resources need to document exactly how it should be freed.

2. Most OSes will free the memory when the program exits, as part of the definition of a "process". The C standard doesn't care what happens, it's beyond the scope of the program. Not all OSes have a full process abstraction, but desktop-style OSes certainly do.

The main reasons to free it before that are:

• If you free memory as soon as possible, often a long time before process exit, your program uses less memory total.
• If you don't free it, and you later want to change your program into a routine within another program, that perhaps is called many times, then suddenly you require many times as much memory as before (memory leak).
• There are debugging tools that will help you identify memory leaks, by warning you about memory that is still allocated when the program exits. These don't really help much if there's a lot of deliberately-leaked junk to wade through.
• If you don't free it and you hit any problems, it's much harder to go back later and find all the memory that needs freeing, than it is to do it right in the first place.
• There are so many cases where you do need to free the memory (to prevent huge memory use in long-running programs), that your default strategy must be to clean pretty much everything up anyway.

The vaguely plausible reasons not to free are:

• Less code.
• If you have squillions of blocks to free individually, immediately before program exit, then it might be much faster to let the OS drop the whole process.
• Stuff which is created on demand and stored in globals might be quite difficult to clean up safely, if you don't know exactly where it's used. Think of some kind of cache that's populated as you go along, that might have MRU rules to limit how much memory it occupies, so it's not an unlimited leak. OK, so this is one bad thing (unrestricted globals) causing another bad thing (unfreed memory), but it's worth knowing about as a reason why you might see unfreed blocks in existing code, and you can't necessarily just go in and fix them.

The reasons for freeing almost always outweigh the reasons against.