I've been using C on some projects for a master's degree but have never built production software with it. (.NET & Javascript are my bread and butter.) Obviously, the need to free()
memory that you malloc()
is critical in C. This is fine, well and good if you can do both in one routine. But as programs grow, and structs deepen, keeping track of what's been malloc
'd where and what's appropriate to free gets harder and harder.
I've looked around on the interwebs and only found a few generic recommendations for this. What I suspect is that some of you long-time C coders have come up with your own patterns and practices to simplify this process and keep the evil in front of you.
So: how do you recommend structuring your C programs to keep dynamic allocations from becoming memory leaks?
Design by contract. Make sure every function comment is explicit about its memory hygiene - that is to say, whether it mallocs and whose responsibility it is to free what was allocated, and whether it takes ownership of anything passed in. And BE CONSISTENT with your functions.
For example, your header file might contain something like:
/* Sets up a new FooBar context with the given frobnication level.
* The new context will be allocated and stored in *rv;
* call destroy_foobar to clean it up.
* Returns 0 for success, or a negative errno value if something went wrong. */
int create_foobar(struct foobar** rv, int frobnication_level);
/* Tidies up and tears down a FooBar context. ctx will be zeroed and freed. */
void destroy_foobar(struct foobar* ctx);
I heartily endorse the advice to use Valgrind, it's a truly fantastic tool for tracking down memory leaks and invalid memory accesses. If you're not running on Linux, then Electric Fence is a similar tool, though less functional.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With