diff libpurple/protocols/oscar/oscar.c @ 31245:6b2b8cc8e7ae

OOH! I think I found the cause of a bug! I changed this function in revision eadc83c534fbbc673a6876ddb1e0bdac8428c07b to try to make it cleaner. When I did that, I added a break here when I should have added a continue. The result is that if we encounter a non-utf8 name for an item in your server side buddy list then we bail out earlier and don't add any server stored buddies to your local list. That's bad. I think this caused a lot of people to not see their complete buddy list. This probably affected ICQ users a lot more than AIM users, because ICQ users tend to use more 3rd party IM clients, and 3rd party IM clients sometimes put non-utf8 text in the name field of these items when they shouldn't. Hopefully fixes #13386
author Mark Doliner <mark@kingant.net>
date Mon, 21 Feb 2011 09:45:47 +0000
parents 3fe2bd895946
children 04576947c4e0
line wrap: on
line diff
--- a/libpurple/protocols/oscar/oscar.c	Mon Feb 21 09:28:03 2011 +0000
+++ b/libpurple/protocols/oscar/oscar.c	Mon Feb 21 09:45:47 2011 +0000
@@ -4000,9 +4000,12 @@
 	/*** Begin code for adding from server list to local list ***/
 
 	for (curitem=od->ssi.local; curitem; curitem=curitem->next) {
-		if (curitem->name && !g_utf8_validate(curitem->name, -1, NULL))
+		if (curitem->name && !g_utf8_validate(curitem->name, -1, NULL)) {
 			/* Got node with invalid UTF-8 in the name.  Skip it. */
-			break;
+			purple_debug_warning("oscar", "ssi: server list contains item of "
+					"type 0x%04hhx with a non-utf8 name\n", curitem->type);
+			continue;
+		}
 
 		switch (curitem->type) {
 			case AIM_SSI_TYPE_BUDDY: { /* Buddy */