Due to the HP-UX socklen_t issue it is insane to use the +w1 warning level.
  It generates more than 1100 warnings on socklen_t related statements.

  Until the issue is somehow fixed we will just use the +w2 warning level.

because the struct is declared on the stack and not all members are used so
we could just as well make struct with only struct members we actually need.

for spotting it).

systems supporting getifaddrs(). Also fixed a problem where an IPv6
address could be chosen instead of an IPv4 one for --interface when it
involved a name lookup.

All but the first test cause an infinite loop or other failure and so
are added to DISABLED.

  Disallow run-time dereferencing of null pointers.

  Disable some remarks:

    #4227: padding struct with n bytes to align member.

    #4255: padding size of struct with n bytes to alignment boundary.

  fixed a CURLINFO_REDIRECT_URL memory leak and an additional wrong-doing:

  Any subsequent transfer with a redirect leaks memory, eventually crashing
  the process potentially.

  Any subsequent transfer WITHOUT a redirect causes the most recent redirect
  that DID occur on some previous transfer to still be reported.

  eventually identified a flaw in how the multi_socket interface in some cases
  missed to call the timeout callback when easy interfaces are removed and
  added within the same millisecond.

was committed just now!

  curl_easy_setopt: CURLOPT_USERNAME and CURLOPT_PASSWORD that sort of
  deprecates the good old CURLOPT_USERPWD since they allow applications to set
  the user name and password independently and perhaps more importantly allow
  both to contain colon(s) which CURLOPT_USERPWD doesn't fully support.

CURLINFO_REDIRECT_URL leaking memory and returning incorrect results when
two URLs are requested. Reported by vmpdemo in bug #2152270

a fresh connection to be made in such cases and the request retransmitted.
This should fix test case 160.  Added test case 1079 in an attempt to
test a similar connection dropping scenario, but as a race condition, it's
hard to test reliably.

the concerns mentioned for 174 and the other guy hasn't returned so I remove
the entry from here now.

  the app re-used the handle to do a connection to host B and then again
  re-used the handle to host A, it would not update the info with host A's IP
  address (due to the connection being re-used) but it would instead report
  the info from host B.