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.

  OBJECTPOINT options. Now we've introduced a new function - my_setopt_str -
  within the app for setting plain string options to avoid the risk of this
  mistake happening.

  for any further requests or transfers. The work-around is then to close that
  handle with curl_easy_cleanup() and create a new. Some more details:
  http://curl.haxx.se/mail/lib-2009-04/0300.html

"pointer to a char pointer".

  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.

the socklen_t issue on this platform.

  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.