Good practice to free malloc's at program conclusion?

I have a simple program which reads a bunch of ini file settings in memory allocated dynamically (malloc), then does stuff in loops for a long time, then ends. When I run valgrind I see that the memory I malloc'ed for my ini strings is not freed.

On the one han开发者_如何学编程d, I think that it shouldn't matter since the program is shutting down (and no memory is leaked in the loops).

On the other hand, I like when valgrind gives me a big pat on the back for cleaning up my own mess. Aside from the pat on the back...is it good practice to release every malloc'ed space upon termination (or just let the OS cleanup)? If it is, how can I track which of my pointers point to malloc'ed memory (versus pointing to string constants which are the defaults) to ensure I'm releasing the right stuff?

I would say the biggest advantage is this: Code always lives longer than you expect, so doing things right usually pays in the long run, even if it means "troubling yourself" today.

Today, your program is simple. But tomorrow, somebody (who may be you) will want to re-use the code for reading and parsing that .ini file. And their program might well need to run for hours, days, or months. By designing your .ini parser to have a clean interface and to manage its memory properly, somebody (who may be you) will thank you someday.

Plus you will probably find it makes your own code easier to write, read, and review today. (Oh yeah, also the valgrind thing.)

Manual resource management is just part of the language. Every experienced C programmer I know designs it in to every program, even the trivial ones, as a matter of habit. If you want to stick with C, my advice is to learn the same habit.

The main advantage to freeing mallocs at shutdown is to help valgrind track down your memory leaks - you can't find true memory leaks when you have pages full of false positives, after all. Apart from that, though, there's no harm in letting the OS clean up.

As for keeping track of string constants vs heap allocated values, one simple policy would be to always use heap values - fill in the defaults with strdup()d strings at startup.

The main advantage is to demonstrate that your code has no leaks, or anyway no leaks of a certain kind. As Nemo says, this makes it easier to reuse the code in future.

Beware though that even if you demonstrably free everything at shutdown, that doesn't prove that your app doesn't have creeping memory usage and hence behaves for all practical purposes exactly as though it has leaks. For example, if your app has some kind of cache with no size limit, that might grow indefinitely during typical use of the app, but all get neatly freed by your shutdown code. That's as bad as a "genuine" leak.

The main disadvantage applies to large apps: the process of churning through all your memory, perhaps pulling a few 10s or 100s of MB out of the page file and into RAM, can be quite slow. It will also slow down whatever other apps got pushed out of RAM to make space for your dying app.

For this reason, if your app ever gets annoyingly slow at shutdown time you could consider doing all that stuff in debug builds only, and/or using a pool allocator so that you can drop big data structures consisting of many small nodes, without having to visit each node.

In this particular case: unless your configuration has thousands of separate items, the parsed contents of your .ini file is probably a small structure of a few small allocations, so on its own it's unlikely to be slow, ever.