talloc issues

[Sam Liddicott]

* simo wrote, On 24/07/09 13:37:
> On Fri, 2009-07-24 at 14:41 +1000, tridge at samba.org wrote:
..
>> I also think that the way that talloc_steal() can become a function
>> that effectively changes the reference count is also a big concern,
>> and not something I think we want.
> 
> I totally agree that making talloc_steal() "special", in this sense, is
> not useful at all, it is actually rather dangerous.
> I think this is something that the original Sam's proposal got wrong
> indeed.

I think it is a matter of perspective, by which I mean it matters very
much and that I have got the right perspective :-) my proposal does not
make talloc steal special from the API users point of view.

The principle is that the code author should be able to steal any valid
talloc pointer. Clearly talloc_steal then is not special.

> Metze and I have discussed a bit what would be appropriate behavior for
> talloc_free() and talloc_steal() after you take a reference. I think the
> conclusion was (Metze correct me if I got something wrong) that 
> 
> A) once talloc_free() is called, any other talloc_free() or
> talloc_steal() on the same talloc context should fail with a double free
> error. Exactly like it would happen if there were no references.

This is a special talloc_steal, in that you can't call it on all valid
talloc pointers, and you will then need an API to help you know whether
or not it is safe to call talloc steal, and then to use this API each
time you use talloc_steal.

Of course my talloc_steal is special from the API implementors point of
view because it really means "remove the original reference parent IF
THERE IS ONE and then add this one" but this is exactly the kind of
thing the API should hide.

Whats the good of me keeping an object alive with talloc_reference if I
can't then go and pass it to a function which is documented to call
talloc_steal ?

Otherwise I agree with what Simo says.

Sam