hmm.. Re: talloc issues

[Rusty Russell]

On Fri, 31 Jul 2009 01:02:22 am Jeremy Allison wrote:
> On Thu, Jul 30, 2009 at 04:58:01PM +0930, Rusty Russell wrote:
> > On Wed, 29 Jul 2009 02:17:00 am Jeremy Allison wrote:
> > > +1. talloc_reference broke my brain a long time ago,
> > > and I don't want to maintain any code that contains
> > > it.
> > 
> > There are patterns which require it; the clearest to me is the "cache"
> > pattern where we want to keep an object around for later reuse, so we
> > hand out references.
> > 
> > Here's a trivial example:
> 
> Yes, that's very clever, but IMHO it's an example of
> "too dangerous to use" design. What is going on with
> the memory references is not obvious to a casual user
> of the cache.

Let's not get too philosophical: how should we implement it?

There are two ways I can see:
1) Have a upcache_free() (or upcache_put()) and insist that everyone use that rather than talloc_free/talloc_unlink.  ie. it's not a talloc object.
2) Return an intermediary which *is* a talloc object, ie.
	struct upstring {
		const char *str;
	};

The original code I posted does *not* allow direct talloc_free(), but does
allow attachment to a talloc hierarchy (indirect free).  Option (1) doesn't
allow either, and option (2) allows both.  But the indirection is messier.

Thanks,
Rusty.