talloc is based on my library called halloc [1], which stands for <i>hierarchical allocator</i>. The idea is that every malloc'ed block can be assigned a parent block. Freeing the parent block also frees all its children in a recursive fashion, and that's about it. I cooked up halloc several years ago when implementing IKE (the IPsec keying protocol) library and it proved to be very useful for reducing the verbosity of the code without loosing any clarity.<p>Tridge fluffed up halloc to make the API more fit and convenient for Samba code, and talloc came out. I still like my version better though because it is simpler and (subjectively) more elegant.<p>[1] <a href="http://swapped.cc/halloc" rel="nofollow">http://swapped.cc/halloc</a>
This feels slightly untrustworthy. What if there are still external references to subfields of a struct? I think it's probably safer to just write explicit constructors (that allocate and initialize) and destructors (to free properly) for the things you use.
Writing a pair of constructor/destructor is not a problem.<p>tmalloc() adds a layer of complexity that is unhealthy to C programs. Are the few seconds you save by using tmalloc() really worth the hours spent to debug memory leaks 6 months later when the project got big and complex with multiple collaborators ? No.<p>Introducing side-effets under the table is the best way to confuse other C programmers when they read your code. It's not worth it.<p>Memory management is part of C, and will always be.
If you don't like it, switch to another language.
One tricky thing here is that this does break the normal memory management semantics. That is, while one nice thing about malloc/free is that you can drop pretty much <i>any</i> implementation of a user-space memory allocator in there without changing your code, this is no longer the case. Whatever replacement allocator you use will have to change its interface, and probably its data structure, to fit the new model.<p>Edit: Also, how is this better than doing something like this<p><pre><code> struct some_complex_struct {
...
};
free_some_complex_struct(struct some_complex_struct * scs) {
...
}</code></pre>
was surprised to see no mention of:<p><a href="http://www.gnu.org/s/hello/manual/libc/Obstacks.html" rel="nofollow">http://www.gnu.org/s/hello/manual/libc/Obstacks.html</a><p>seems like a very similar concept / means to an end?
Or you could use C++ and RAII. It's an excellent fit for the problem that's been presented.<p>Though I do understand, there are some very special projects that can't use C++, and must use C. I'd say in most cases, the extra machinery you get with C++ outweighs the small performance penalty you get by going with straight C.