about talloc_steal()

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tridge,

> Anyway, I think it is a mistake to blame talloc_steal() and
> as a consequence to avoid code that uses it. Avoiding code
> that uses lots of talloc_reference() calls is much more
> reasonable, and hopefully we can reduce the usage of
> that over time.

My concern is more about clarity of code.  Like you said, this
is not the fault of talloc_steal().  It is more like the question
of nuclear power. Used correctly, it can be very good.  Used
incorrectly, and it can be devastating.  Personally, I would
enjoy debugging someone else code that use talloc steal about as
much as I enjoy debugging random Perl code written by other
people.  The experience can be pleasant but more often that
not, it's pretty painful.  My main concern is surrounding
contexts that out last a  single function invocation.  Tracking
within a single function is trivial.

talloc_steal() can make elegant code but I'm not convinced that
given developer turnover in open source projects, it can
be used to create maintainable code.  It is much more intuitive
to me, or at least to simpler, create a new talloc context pointer
when the lifetime of data is different.  And that is something
that everyone should be able to understand at first glance.






cheers, jerry
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFE4T37IR7qMdg1EfYRAnQ2AJ9/+3OtM3aiMMUcOC4MHlbniDvijgCcDDOg
p40umZzqJK1sxQfRs3a+5Lo=
=IGv6
-----END PGP SIGNATURE-----