Use after talloc_free...

[simo]

On Thu, 2009-11-12 at 15:56 +1030, Rusty Russell wrote:
> On Thu, 12 Nov 2009 02:08:10 pm simo wrote:
> > On Thu, 2009-11-12 at 12:28 +1030, Rusty Russell wrote:
> > > See previous mail detailing my reservations about NULL-ing and implicit
> > > arg modifying tho...
> > 
> > What's wrong with "implicit" arg modifying ?
> 
> In C, fn(x) can't modify x.  If it does, it's a hell of a surprise to the
> reader.  That's why TALLOC_FREE has to shout that it's a macro, but it's
> still a poor warning that magic is happening.
> 
> > I mean that's the only reason to use TALLOC_FREE(), it's not like you
> > are going to be confused about that, or are you ?
> 
> *I* know it, but what about everyone else reading talloc-using code?
> (Hopefully, that will be most hackers in the universe RSN ;)
> 
> And I think *everyone* should be using the safer variant of free (whatever
> it's called) for it to be effective.  It should be clear that it's preferred,
> and TALLOC_FREE is ugly.
> 
> If we were doing talloc from scratch, we should make talloc_free() destroy
> its arg and have some lesser variant for where that's not possible.
> 
> We could be daring and call the new variant tfree()?

Ok, now I remember why I made my talloc_zfree() a macro although I tried
to make it a function that would take a pointer.

The reason was that the function prototype would have had to be
something like:

void talloc_zfree(const void **ptr);

The problem is that in C void ** is a bad thing apparently, but we have
no choice because a TALLOC_CTX is just a void pointer renamed.

So in the end I just settled for the macro.

Although given that now talloc_free() can fail we should check that in
the macro and not zero the pointer if the free fails I guess..

Simo.



-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>