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.
IE8 can't handle the W3C method of stacking an image on a linear gradient. Since all supported browsers have other ways besides the W3C method of doing this, we can 'fix' this by removing the W3C method. At some point in the future when browsers all use the W3C method, we can look for a different solution, or drop IE8 support ;)
Mitchell Livingston