We used to pass no button text + response_id pairs when creating the dialog because only gtk_dialog_add_button() would return back the actual button widget s.t. we could use a grab on it. However as of GTK+ 2.20 we can use gtk_dialog_get_widget_for_response() to get the button, so we can create dialogs in the more common way (which also fixes the gcc warning)
Once we've scored all n candidates, we sort them by score so that we can pick out the k best candidates. If n is large, sorting them can be expensive. If we use the Selection Algorithm, we select in O(n) without having to sort.
There are actually two different implementations of the byte-counting in that function: a slower implementation was added prior to 2.40 in r12918 to double-check the standard implementation. This checking was added to help smoke out a bug that was fixed in r12920, but I forgot to remove that slower implementation.
The webseed in question is downloading from an ubuntuone.com url. We ask for piece-sized ranges in a couple of different concurrent connections, and curl hints to the server that it's okay to gzip the response, or deflate it, or leave it raw. It looks like there's a bug in the server or in libcurl (or, somehow, Transmission) that's not compressing or decompressing these responses correctly -- we never get the right number of bytes in the response from libcurl. If we ask for the contents uncompressed, the download progresses towards completion.
As an aside, when testing this I noticed that deluge is a lot faster than Transmission on this torrent. In order for Transmission to reach parity here, webseed.c needs to know when it's appropriate to have more than 4 concurrent tasks and/or be able to request ranges > the torrent's piece size.
Found by llvm's static analyzer. This is a minor issue since the leak is in an automated test rather than in shipping code, but it's still better to fix it.
static-build found a potential NULL pointer dereference. The circumstances where this could get triggered don't seem very likely, but doesn't hurt to fix the warning.
scan-build found similar warnings in these two functions relating to allowing NULL pointers to be passed as arguments to functions that don't allow NULL. So now those NULL checks are made explicit before the function calls.
Mitchell Livingston