recent gcc versions give far too many false positives for this to be valuable

that made curl run fine in his end. The key was to make sure we do the
SSL/TLS negotiation immediately after the TCP connect is done and not after
a few other commands have been sent like we did previously. I don't consider
this change necessary to obey the standards, I think this server is pickier
than what the specs allow it to be, but I can't see how this modified
libcurl code can add any problems to those who are interpreting the
standards more liberally.

one!

is due to now using emacs to sort but I'm not in a mood to fix it better just
now.

The CONNECT problem is now bug #25 planned to get fixed in next release.

fixed after 7.14.1

we have a fancier valgrind error parser these days and it seems to work rather
well

true since the getdate() parser code rewrite

  CURLOPT_COOKIEFILE), add a cookie (with CURLOPT_COOKIELIST), tell it to
  write the result to a given cookie jar and then never actually call
  curl_easy_perform() - the given file(s) to read was never read but the
  output file was written and thus it caused a "funny" result.

- While doing some tests for the bug above, I noticed that Firefox generates
  large numbers (for the expire time) in the cookies.txt file and libcurl
  didn't treat them properly. Now it does.

fails to open/read files etc to help users diagnose why it doesn't do what
you'd expect it to. Converted lots of old messages to use the new generic
function I wrote for this purpose.

site responds with bad HTTP response that doesn't contain any header at all,
only a response body, and the write callback returns 0 to abort the
transfer, it didn't have any real effect but the write callback would be
called once more anyway.

  converts the request to a GET, but now instead makes it a POST of no data
o The time condition illegal syntax warning is now inhibited if -s is used.

too big