Chen pointed out how curl couldn't upload with resume when reading from a
  pipe.

  This ended up with the introduction of a new return code for the
  CURLOPT_SEEKFUNCTION callback that basically says that the seek failed but
  that libcurl may try to resolve the situation anyway. In our case this means
  libcurl will attempt to instead read that much data from the stream instead
  of seeking and that way curl can now upload with resume when data is read
  from a stream!

  Wegener pointed out that CURLINFO_APPCONNECT_TIME didn't work with the multi
  interface and provided a patch that fixed the problem!

Previous workaround proved useful, and finally did not trigger any warning!

Previous workaround proved useful, but triggered the following warning:

warning #556: a value of type "volatile Curl_addrinfo *" cannot be assigned to an entity of type "Curl_addrinfo *"

The #pragma optimize("", off) attempt did not fix the problem and SIGSEGV's in Curl_freeaddrinfo() were back.

Previous 'volatile' variables workaround proved useful, but it triggered the following warning:

warning #167: argument of type "volatile Curl_addrinfo *" is incompatible with parameter of type "void *"

setup_once.h.  Inclusion of each header file is based on the definition of
NEED_MALLOC_H and NEED_MEMORY_H respectively.

  how it occurs (http://curl.haxx.se/mail/lib-2009-04/0289.html). The
  conclusion was that if an error is detected and Curl_done() is called for
  the connection, ftp_done() could at times return another error code that
  then would take precedence and that new code confused existing logic that
  works for the first error code (CURLE_SEND_ERROR) only.

  proxy. libcurl would then wrongly close the connection after each
  request. In his case it had the weird side-effect that it killed NTLM auth
  for the proxy causing an inifinite loop!

  I added test case 1098 to verify this fix. The test case does however not
  properly verify that the transfers are done persistently - as I couldn't
  think of a clever way to achieve it right now - but you need to read the
  stderr output after a test run to see that it truly did the right thing.

  Storsjo pointed out how setting CURLOPT_NOBODY to 0 could be downright
  confusing as it set the method to either GET or HEAD. The example he showed
  looked like:

   curl_easy_setopt(curl, CURLOPT_PUT, 1);
   curl_easy_setopt(curl, CURLOPT_NOBODY, 0);

  The new way doesn't alter the method until the request is about to start. If
  CURLOPT_NOBODY is then 1 the HTTP request will be HEAD. If CURLOPT_NOBODY is
  0 and the request happens to have been set to HEAD, it will then instead be
  set to GET. I believe this will be less surprising to users, and hopefully
  not hit any existing users badly.

  out to be leaking cacerts. Kamil Dudka helped me complete the fix. The issue
  is found in Redhat's bug tracker:
  https://bugzilla.redhat.com/show_bug.cgi?id=453612

  There are still memory leaks present, but they seem to have other reasons.

Improved Symbian support for SSL.

Avoid unnecessary'if-else' nesting.

PS: Once again, sorry if the added files have executable perms on Linux.

PS: Sorry if the added file has executable perms on Linux, I didn't found anything related to it...