[PATCH] Make loadparm more common

[Volker Lendecke]

On Thu, Apr 03, 2014 at 01:45:47PM +0200, David Disseldorp wrote:
> > > > No, I'm not willing to add any more talloc_tos() to this area of the
> > > > code.  Almost all the odd unexpected failures caused by this patch set
> > > > were due to new talloc_tos() calls, because not all callers had a
> > > > talloc_stackframe().    
> > 
> > Well, those is a bug then, and the developer mode to panic
> > in that case was introduced so that we can fix the callers up.
> > 
> > I think adding talloc_tos() is way better than adding talloc(NULL,...)
> > since this way we can at least easily spot the leaks.
> 
> I disagree. IMO tallocations on the null context are much more readable
> and debugable. For talloc_tos() tallocations one needs to consider
> whether a stackframe is around, and when the next garbage collection
> could take place.

Just assume in all routines except external interfaces that
a talloc stackframe is around.

There is no garbage collection, freeing the stackframe is
fully under your control if you add an explicit
talloc_stackframe() to your function.

If you don't do an explicit talloc_stackframe() in your
function, assume that the memory will not be around very
quickly after you returned from your function.

talloc_tos() does not liberate you from talloc_free'ing your
memory. I consider leaking on talloc_tos() bad style. It is
purely a safety measure against accidential memory leaks, in
particular in error return paths. That's the basic
difference: It's bad style versus a potentially devastating
memory leak.

I believe that talloc_tos() has contributed big ways to the
fact that memory leaks are almost gone from the Samba
buglist. Not fully, true, but memleaks are almost no issue
anymore.

Hope that clarifies things a bit.

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