talloc_tos(), returning talloc_tos() memory and the talloc_stackframe order protection

[Andrew Bartlett]

On Fri, 2018-06-15 at 14:29 +0200, Volker Lendecke via samba-technical
wrote:
> On Fri, Jun 15, 2018 at 02:07:26PM +0200, David Disseldorp wrote:
> > I disagree. For short-lived heap-backed allocations, creating a new
> > talloc child under a longer-term context and subsequently freeing it
> > allows one to easily determine the lifecycle of the variable. This is
> > not the case for talloc_tos() allocations without analysing the state of
> > the talloc stackframe through the entire call chain - "quickly" is
> > completely arbitrary.
> 
> The problem is -- it's easy to forget to free the short-lived talloc
> child. Because I've fallen into this trap more than once, I wrote
> talloc_tos().

Isn't this why Rusty did the work to ensure that for developers, if you
don't call talloc_free() on the talloc_stackframe() context we abort
when we get to the next one?  

That seems to me to be a pretty solid protection.

> > A function returning memory allocated on the current stackframe without
> > taking a talloc_tos() parameter is evil IMO, as it's completely unclear
> > from the caller where the memory came from.
> 
> Absolutely correct. You should NEVER return objects hung off
> talloc_tos() from a function. This is evil IMHO too. If you have a
> function that returns stuff, hand it a talloc context. This is vastly
> different from temporary memory within a function where it does not
> matter when exactly it's freed, immediately or a millisecond later.

Why do we have functions like create_conn_struct_tos() then?

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba