[QUICK] talloc bugs

[Sam Liddicott]

* Rusty Russell wrote, On 01/07/09 12:06:
> On Wed, 1 Jul 2009 05:39:51 pm Sam Liddicott wrote:
>   
>> There is no talloc_steal and talloc_free; only talloc_reparent.
>>     
>
> Hi Sam,
>
> 	OK, I'm confused about talloc w/o talloc_free.
>
> 	Do you have a patch I can look at?
>   
It was a hypothetical ideal talloc where all parents are equal and
therefore there is no talloc free because it would require an error to
be raised on multiple parents, thus ruining unexpectedly at runtime the
wonderful facility of multiple parents[1]

We then quickly pass through this utopia and realise how malloc
compatible code seriously needs a talloc_free and realise how trivially
we can provide it by stashing the allocating pointer in the talloc chunk.

Thus talloc_free re-appears into existence but without all of the
conflicts and ambiguity it has hitherto had. Talloc_free is now for
backwards compatibility, for convenience for simple code, and yet
totally compatible with the new truly egalitarian reference model.

We then realise that it means current use of talloc free also happens to
be legitimate by these new rules.

So there is no patch to remove talloc_free, we just re-frame talloc and
watch the ambiguity and conflict vanish in this newly framed talloc
which happens to be suspiciously like the old talloc apart from a patch
which prevents the ambiguity introducing promotion from "equal
reference" to "parent" - because now "parent" doesn't mean parent in the
old talloc v0.1 sense, it means "allocating reference saved for the
convenience for backwards compatible talloc_free" and has no
hierarchical meaning whatsoever. All the hierchy is kept in tc->refs

Sam

[1] or (depending on your point of view) making use of talloc_free a
risky proposition often only to be avoided the way tridge avoided it by
yanking out one of the parents - but as all parents are equal it gets
difficult to do this with a straight face