To free() or not to free() before an exit() ?
Should you free() all alloc'd buffers before calling exit()? Why (not)?
|
You do not need to free your memory before exit. During the termination of the process the kernel also deletes the memory mappings which were associated with that process. So everything is "freed" implicit by the kernel.
|
I think it is better practice to free everything before your program terminates. One important advantage I can imagine is that when you run those utilities to detect memory leaks, they will return exactly zero bytes of allocated memory before exiting the program. When you leave memory allocated at the end of the program you never know whether you have a leak.
Besides, if you have a function where you allocate memory, you have to free allocated memory anyway before you return. (Unless you pass the pointer back to the caller). Main () is just another function, so why not follow this behavior? jlinkels |
I agree with both points. While it's not necessary, it is good practice. Calling free() is kind of like putting curly braces around the body of "if" statements - it's not always necessary, but if you get into the habit of doing it, it will never come back to bite you.
|
Quote:
It's always better to do a explicit free(). If you were to extend the program with atexit() handlers, the fact that some memory should/shouldn't be available may be an issue. They're called when you use the exit() call, so don't count on the OS to the work for you. |
Quote:
So my advice still is to not loose yourself in such a fussy (and needless, as I mentioned in my first post) memory tracking. Quote:
|
Quote:
Anyway.. for my answer to the original question... it is always best where possible to free memory you allocate. You never know when you might end up coming back to your code later and incorporating it into a bigger program and forget you didn't do all your memory accounting in the past. |
Writing programs which exit in nested functions is generally considered as bad programming practice. You should leave functions at the return statement, not somewhere in the middle.
You are right that if your program receives a SIGHUP, it is killed in the middle, and you have to leave cleanup to the OS. However, this is not normal practice. The program ought to be WRITTEN such that it leaves nicely at the end of main. And has cleaned up all the garbage. If you make it a practice to leave your program somewhere in the middle, leaving it to the OS to clean up your memory allocations, and you ever have to find a memory leak, I wish you lots of good luck. BTW, Primo might overdo it with curly braces around everything, but this can be considered defense or robust programming. Better check twice, we all make errors, others make (more) errors, the unexpected happens. That is why it is possible to make a program in plain old C behave like it is bug free. And that is why most GUI based programs, written in an OO language, with zillions of things assumed and not checked or double armed starts to behave oddly sooner or later. jlinkels |
For a shell programming assignment, calling exit() within the function that handled all of my ridiculously simple builtins in order to (obviously) implement the builtin 'exit' was the simplest thing to do that does the right thing. The major question I would have is if doing a free of all your memory yourself is going to be slower than letting the kernel do it for you. Maybe the best option is to write the code within a #ifndef NDEBUG block. It might help to apply RAII to C code as best as you can.
|
Quote:
And yes, defensive programming is a very good thing! But I think even here are limits; if you convulsive try to hold your defense in any possible case, you may forget what you actually are fighting for. A defensive pattern in programming is only useful, if it avoids hard detectable (thus time consuming) bugs and errors which may relatively often occur. Your brace-if was a good example for this. But the brace-function-call to avoid bad macros.... First I don't use a macro unless I don't know what it does and second I never (in almost 15 years of programming experience) came across such a macro that would make i possible to put it between braces (at least I don't remember). -Surely everyone can construct such one, but fact is, that they must be very, very rare in the real world and putting every function call between braces is definitely not worth the effort - maybe it's defensive but it's no good style! My conclusions of this: Yes I agree, that a program flow should be clear designed and it is desirable to be able to free memory before an exit(), but the reality shows, that it is quite easy to run into a situation where this is just not given; and in such a situation you don't need to care much about it. And yes, defensive programming is a must today, but while doing so you should have the feeling, that the advantages you gain are bigger then the costs you pay. |
Quote:
Quote:
|
All times are GMT -5. The time now is 06:44 PM. |