svn commit: samba r23290 - in branches: SAMBA_3_0/source/nsswitch SAMBA_3_0_26/source/nsswitch

[simo]

On Sat, 2007-06-02 at 11:32 -0700, Jeremy Allison wrote:
> On Sat, Jun 02, 2007 at 09:53:20AM -0400, simo wrote:
> > 
> > I am sorry to contradict you Jeremy, but it is not a matter of taste.
> > If you alloc all array children on the array, then if you want to
> > steal/move/free the array, you have to care _only_ about the array
> > pointer. You don;t risk leaving behind children on the wrong context,
> > and maybe have them freed while you are still keeping around the parent.
> 
> That's a very good point, and one I hadn't considered.
> Thanks for setting me straight on this.
> 
> I must confess I do find the "invisible heirarchy"
> of talloc extremely confusing. At least in C++
> heirarchy are explicitly declared.

This is true, but sometimes, being invisible make it so more powerful :)

> > talloc_steal/talloc_move are the reasons to not alloc everything on the
> > generic mem_ctx, but to build memory hierarchies that reflect structure
> > hierarchies :)
> 
> Indeed, but I wish there was a way to express this in
> the definitions. I guess if you're careful the structure
> definition can be used here, but definitions aren't
> always so clear.

You definitively must be careful.
Since I started working with the new talloc I decided to change my
mindset. Now I give for granted that if I have a structure and I have to
allocate stuff in it, then the memory hierarchy follows the structure I
am using.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org