[Patches] Preparation for tevent impersonation (part1)

[Volker Lendecke]

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().

> 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.

> > If talloc_tos() is no longer en vogue, we need a similarly concise
> > abstraction.
> 
> In talloc we already have a very nice hierarchical allocator which,
> alongside the stack, is perfectly capable of providing short lived
> memory allocations.

How do we make sure we don't leak this memory, short of the clear
convention using talloc_tos()?

Thanks,

Volker

-- 
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
http://www.sernet.de, mailto:kontakt at sernet.de