talloc -- Eureka*

[Michael Brown]

On Thursday 30 July 2009 03:04:17 Rusty Russell wrote:
> How about: talloc_attach/detach or talloc_connect/disconnect?
>
> A completely new namespace is far clearer, esp. if we're going to deprecate
> the old ones.

+1

The names talloc_get() and talloc_put() would give you naming consistency with 
reference counting APIs used in the Linux kernel, if that's any 
consideration.

If I were facing the pain of trying to make this kind of change, I would be 
tempted to:

- introduce a completely new API pair e.g. talloc_get()/talloc_put() which 
count references sanely, and are completely orthogonal (and invisible) to 
users of talloc()/talloc_zero()/talloc_steal()/talloc_free().

- mark talloc_reference() as __attribute__((deprecated)).

- provide a wrapper talloc_old_reference() for talloc_reference() which is not 
marked as deprecated, and just calls talloc_reference().

- do a global search/replace on the suspect code (samba4?) to replace 
talloc_reference() with talloc_old_reference(), to avoid the huge noise 
of "deprecated function" warnings.

- add "reviewing and replacing code that calls talloc_old_reference()" to a 
very long-term TODO list

It's possible that a tool such as sparse could be used to track down safe uses 
of talloc_old_reference() automatically, by adding extra information beyond 
the C type to variable/parameter declarations.  (I don't know how to do this 
off-hand, but I do know that Linux uses extra declarations to mark pointers 
as being in user or kernel address spaces, and to mark integers as little- or 
big-endian; this is information that is invisible to the compiler but that 
can be used by sparse to perform checks beyond the compiler's ability.)

Michael