Writing a pair of constructor/destructor is not a problem.
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.
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.
Memory management is part of C, and will always be.
If you don't like it, switch to another language.
What side effects were introduced "under the table"? talloc introduces entirely new functions, it doesn't override standard malloc/free. All of the new behaviors are rather explicit.
As for large project with collaborators: if the project doesn't already have coding standards or doesn't have a code review process for new members then they're already headed down a bad path. And anyone blindly introducing talloc into an existing project without first getting agreement from other participants and taking steps to smooth integration is irresponsible.
The issues you give aren't reasons to dismiss talloc. Bugs, implementation flaws, design limitations are some valid reasons. By your argument, anything layered on top of the C standard library should be avoided.
I understand that talloc adds complexity, but what large project with multiple collaborators does not already have some memory management policy?
C forces you to explicitly communicate who is responsible for allocating and freeing each piece of memory. Isn't talloc just providing a mechanism that helps with this?
If talloc is part of a project's memory management policy, contributors not using it consistently are by definition not following the policy consistenly. This would be a problem regardless of mechanism.
You get kmalloc() and kfree(), which are very similar to malloc() and free(). (Okey you also get kmem_cache_alloc()/kmem_cache_free() which gives you the ability to provide a ctor/dtor, but they are explicit)
tmalloc() does too much: The day you have some memory corruption / leak, you'll start being scared of using tmalloc().
tmalloc() is a structured way of doing memory management within C. It's no different than all the other ad-hoc structured (or more often unstructured) memory management schemes that evolve within C programs, with the exception that it's semantics are at least documented.
tmalloc() is memory management. As are other, alternative memory allocation strategies, chosen for better performance for certain applications. The notion that there is only one right way to do things is quaint, even if you're talking about Python.
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.
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.
Memory management is part of C, and will always be. If you don't like it, switch to another language.