I think C programmers would be better of moving to a small subset of C++ with destructors. This library tracks the link between a struct and its child objects for each instance of the struct (both the application and this library know about the link between a user and its username field). In C++, the knowledge 'free the pointer pointed to by field X' is kept only once. If you have lots of objects, that will add up.
Even if you don't want to move to C++, I don't think this is easier than writing separate functions 'allocAnX' and 'freeAnX', and being disciplined to always use them.
The 'reference counting' mentioned in the introduction may be a reason to use this instead, but it could not find it in the documentation elsewhere. Did I overlook that?
You're right that talloc has a memory overhead relative to smart pointers or a free_foo() function; talloc'ing up an int is very inefficient. Note that you can add a talloc-integrated "destructor" at zero marginal cost, so e.g. an array of a million pointers to individually-allocated int's could let talloc manage the vector and free the int's in the destructor. (That is, you can de-talloc part of a talloc'ed memory hierarchy.)
Additionally, malloc also has a runtime and memory cost; like talloc's, this cost is high enough to discourage arrays of pointers to individually allocated int's and low enough that it doesn't matter for arrays of int's. The one time I played around with talloc (for a network daemon), I didn't really run into any allocations where I'd hesitate to use talloc but not to use malloc. (I forgot the numbers; a quick Google suggests that talloc adds 96 bytes to malloc's 16 bytes of overhead.)
That said, just being disciplined about memory usage seems to work decently well, too. (For expert programmers with good tools, usually; it's a hard problem.)
> I wonder whether it was possible to make this more transparent for C programmers.
Actually, it is almost too transparent for C programmers:
>> From the programmer's point of view, the talloc context is completely equivalent to a pointer that would be returned by the memory routines from the C standard library.
You'd never be able to make it just a drop in replacement, because it's not just about the allocation and freeing. The interesting stuff is specifying the hierarchies so that freeing a higher object frees lower ones too. Existing code using malloc/free wouldn't be doing that.
