pidgin: 44df11dd: The variable we use to keep track of the...

[markdoliner at pidgin.im]

-----------------------------------------------------------------
Revision: 44df11dd9d1db0245be1ab1ac5410821b1c9f2af
Ancestor: 7025d33c9a1201cc806b4a7d7053cd58c5e1b312
Author: markdoliner at pidgin.im
Date: 2008-09-04T18:04:29
Branch: im.pidgin.pidgin
URL: http://d.pidgin.im/viewmtn/revision/info/44df11dd9d1db0245be1ab1ac5410821b1c9f2af

Modified files:
        libpurple/sslconn.h

ChangeLog: 

The variable we use to keep track of the watcher of the ssl connection
should be unsigned.  This isn't really a problem in Pidgin, where we
use glib's mainloop and GIOChannels because glib starts assigning the
handle IDs sequentially starting from 1.

But if an eventloop implementation ever returns a handle ID greater
than the largest possible signed integer (2,147,483,647) then we
won't be able to remove the watcher because purple_ssl_close() in
sslconn.c only removes it if inpa > 0, and since it interprets inpa
as a signed value then handles over 2,147,483,647 appear as negative
numbers.

I stumbled upon this when playing around with libevent, which can
use epoll.  My implementation generated a random handle ID which
was sometimes greater than 2,147,483,647.

I don't believe this breaks binary compatibility.  And I don't think
it breaks source compatibility, but I guess it might depend on what
compiler you're using.

-------------- next part --------------
============================================================
--- libpurple/sslconn.h	d4d2265808306bdc97e927da311fa1fbf3203295
+++ libpurple/sslconn.h	9351ae6d31423524f7765608deb779665a7ccf71
@@ -67,7 +67,7 @@ struct _PurpleSslConnection
 	int fd;
 	/** Glib event source ID; used to refer to the received data callback 
 	 * in the glib eventloop */
-	int inpa;
+	guint inpa;
 	/** Data related to the underlying TCP connection */
 	PurpleProxyConnectData *connect_data;