[RFC] Making talloc_reference() safer.

[Volker Lendecke]

On Mon, Oct 24, 2011 at 04:46:27PM -0700, Jeremy Allison wrote:
> On Mon, Oct 24, 2011 at 05:50:38PM +1100, ronnie sahlberg wrote:
> > 
> > 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.e. offer something like this
> > talloc_new_ref(...)
> > instead of using the pattern
> > talloc_new(...)
> > ...
> > talloc_make_reference_ptr(...)
> 
> Yes, this makes much more sense to me too.

On further thought, I might be okay with calls like

talloc_set_referencable()
talloc_unset_referencable()
talloc_is_referencable()

talloc_reference() would return NULL for a non-referencable
object, gensec could return EINVAL by first checking via
talloc_is_referencable(). talloc_free() on a referencable
object would just abort. Abort to me is preferable over just
leaking because this makes sure we don't leak by accident.

I still don't like talloc_reference() at all and I would
much rather live without it, but with the set of calls it
can become a very obvious part of an API. It complicates it,
but if API developers see it as necessary, so be it. We can
always work on alternatives.

Why no talloc_new_referencable() as I first thought? This
would trickle up all credential_init() style calls and
unnecessarily clutter those APIs for non-referencing use.

With best regards,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen