[QUICK] talloc bugs

[Sam Liddicott]

* simo wrote, On 01/07/09 13:27:
>
> No, it's not *a* person, there are libraries that depend on talloc, so
> it is a chain of dependencies that is quite big.
> The only way to solve the problem, would be to fork talloc, but I think
> the changes made are not important enough to warrant a fork.
>   
I can think of some more changes... but don't let this muddy the current
discussion

Ultimately I want gnome (and vala) to use talloc, because it's the only
memory management system thats barely managable  across complex programs.

To make up for lack of IUnknown::AddRef/Release, modules using talloc
will be able to supply a struct of function pointers with names like:
ref, unref, can_free, transfer_owner etc, and add these to a talloc
context, affecting child allocations.

Each talloc-ation will have a pointer to such a struct in its talloc_chunk.

..and so systems with their own ref counting system but which use
talloc will finally be able to share objects effectively by filling in
the function pointers to the functions of their own system.

This means that libsmbclient could do:
  me->private_data = talloc_ref(me, gtk_something);

and have the gtk object built-in reference counting work properly.

If the referenced system supported counting but not specific pointer
references then talloc could manage the specific pointers for it and
just tell the backend reference system to increase or decrease it's count.

By means of a tree of pointer bits (perhaps like the smb wire key stuff)
Talloc will also be able to tell if a pointer was allocated by talloc,
and maybe which library client allocated it; and thus avoid trying to
call these functions on non-talloc pointers.

That's my plan for talloc. Cards on the table. Hope it doesn't require a
fork.

Sam