[RFC] Making talloc_reference() safer.
rusty at rustcorp.com.au
Mon Oct 24 19:03:47 MDT 2011
On Mon, 24 Oct 2011 17:50:38 +1100, ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
> > Also add a warning for talloc_parent() and talloc_parent_name().
> Why just a warning and not a run time error?
> I think it is almost always a mistake when mixing single-parent
> hierarical allocations with a multi-parent graph allocation.
> But this is a step in the right direction.
Indeed. I have an implementation (ccan/talloc_link), entirely outside
talloc. You explicitly bless a NULL-parented object with
"talloc_linked(ctx, newobj)", then you can "talloc_link(ctx, obj)" and
But it's sub-optimal because talloc knows nothing about it:
1) talloc_parent() and talloc_steal() still "work". Oops.
2) talloc_report et. al don't show the references.
And I agree on aborting for new projects, but not for SAMBA. Another
global flag I think...
> The name of this "talloc_may_reference()" could be changed to
> something more explicit, but I dont know exactly what it would be
> Maybe rename it to "talloc_make_referenced_ptr()" to indicate that
> what it does is not really
> just changing it so that you can, if you want, create references,
> but instead indiate more clearly that you MAKE some change to this
> object that hcanges the semantics of it from hereon and forward.
> Even better I think would be if you had a new set of creator functions
> where you could set the "no longer hierarical, now its multi-parent
> referenced" already from the initial creation. That would be even
> better imho to force the choice of api at object creation time and
> not create it as ahierarical object and then later "upgrade" it to a
> different model.
I actually like this, though there are 6 variants we'd have to code
(single, array, size, then zeroing variants of each).
If we're going to rip apart the API, I'd like to separate it into
talloc_ref(), talloc_array_ref(), etc? Then talloc_add_ref(),
More information about the samba-technical