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 *"

  Koenig pointed out that the man page didn't tell that the *_proxy
  environment variables can be specified lower case or UPPER CASE and the
  lower case takes precedence,

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.

  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.