pidgin.next.minor: 88d15a78: g_hash_table_ref() / g_hash_table_unref(..

[Evan Schoenberg]

On Apr 30, 2008, at 2:47 PM, Mark Doliner wrote:

> I haven't tested this or dug around very much, but wouldn't this  
> crash?  It
> looks like you're not actually copying the data but instead just  
> copying
> references to the strings in the original hash table, which are  
> freed by
> whoever called serv_join_chat().

Yeah, you're right. It worked in my testing, but it's not reliable  
memory management.  I'm used to working in code in which everything  
automatically has reference counting, so adding an object to a  
dictionary which retain it without question... I'll fix it right now.  
Thanks for the catch.

> I'm also wondering if it would be better if
> the core gave the hash table to the PRPL and it was the PRPLs  
> responsibility
> to free it.  But I guess that might require an API change (or we  
> could just
> live with the fact that 3rd party PRPLs would leak memory until they  
> started
> freeing the hash table).

I think it's much more straightforward when ownership of objects  
doesn't change with calls; changing ownership would avoid allocation  
of a second set of objects, but the result would be that any code  
calling serv_join_chat() would need to remember not to free the  
GHashTable it had created, which feels awkward to me.

-Evan