[prev in list] [next in list] [prev in thread] [next in thread]
List: pidgin-devel
Subject: Re: pidgin.next.minor: 88d15a78: g_hash_table_ref() /
From: Evan Schoenberg <evan.s () dreskin ! net>
Date: 2008-04-30 21:02:53
Message-ID: 50EADA2C-626C-40D6-84C0-BE62379C9E7C () dreskin ! net
[Download RAW message or body]
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
_______________________________________________
Devel mailing list
Devel@pidgin.im
http://pidgin.im/cgi-bin/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic