Save the errno value immediately after a connect() failure so that it
won't get reset to something else before we read it.

Bug: http://curl.haxx.se/mail/lib-2011-10/0066.html
Reported by: Frank Van Uffelen and Fabian Hiernaux

Renamed the variable from 'proto' to 'level' simply because it is not
protocol you set but level and that is the name of the argument used in
man pages and the POSIX documentation of the setsockopt function.

When connecting, make sure TIMER_CONNECT is set.

When using the multi interface, a SOCKS proxy, and a connection that
wouldn't immediately consider itself connected (which my Linux tests do
by default), libcurl would be tricked into doing _two_ connects to the
SOCKS proxy when it setup the data connection and then of course the
second attempt would fail miserably and cause error.

This problem is a regression that was introduced by commit
4a42e5cd that was introduced in the 7.21.7 release.

Bug: http://curl.haxx.se/mail/lib-2011-08/0199.html
Reported by: Fabian Keil

With "@unittest: [num]" in the header comment for each tested function.
Shows we have a log way to go still...

It was mostly typecasted to int all over the code so switching to long
instead all over should be a net gain.

Fix compiler warning: conversion may lose significant bits

Fix the return type of the callback to match close() and make use of it.

Introduced the initial setup to allow closesocket callbacks by making
sure sclose() is only ever called from one place in the libcurl source
and still run all test cases fine.

When connecting to a socks or similar proxy we do the proxy handshake at
once when we know the TCP connect is completed and we only consider the
"connection" complete after the proxy handshake. This fixes test 564
which is now no longer considered disabled.

Reported by: Dmitri Shubin
Bug: http://curl.haxx.se/mail/lib-2011-04/0127.html

"if(a)" is our style, not "if( a )"

By the use of a the new lib/checksrc.pl script that checks that our
basic source style rules are followed.

asyn-ares.c and asyn-thread.c are two separate backends that implement
the same (internal) async resolver API for libcurl to use. Backend is
specified at build time.

The internal resolver API is defined in asyn.h for asynch resolvers.

Found with codespell.

When checking if an existing RTSP connection is alive or not, the
checkconnection function might be called with a SessionHandle pointer
being NULL and then referenced causing a crash. This happened only using
the multi interface.

Reported by: Tinus van den Berg

Bug: http://curl.haxx.se/bug/view.cgi?id=3280739

Introducing a few CURL_SOCKOPT* defines for conveniance. The new
CURL_SOCKOPT_ALREADY_CONNECTED signals to libcurl that the socket is to
be treated as already connected and thus it will skip the connect()
call.

When the callback returns an error, this function must make sure to return
CURLE_ABORTED_BY_CALLBACK properly and not CURLE_OK as before to allow the
callback to properly abort the operation.

The idea that the protocol and socktype is part of name resolving in the
libc functions is nuts. We keep the name resolver functions assume
TCP/STREAM and we make sure that when we want to connect to a UDP
service we use the correct UDP/DGRAM set instead. This bug was because
the ->protocol field was not always set correctly.

This bug was only affecting ipv6-disabled non-cares non-threaded builds.

Bug: http://curl.haxx.se/bug/view.cgi?id=3154436
Reported by: "dperham"

As the function doesn't really use the connectdata struct but only the
SessionHanadle struct I modified what argument it wants.

When using the multi interface and connecting to a host name that
resolves to multiple IP addresses, there was no logic that made it
continue to the next IP if connecting to the first address times
out. This is now corrected.

- Show address string from proper buffer in case of connection failure.

- Try next address when inet_ntop() fails.

Reinstate IPV6 build variable that got removed.

The IP version choice was previously only in the UserDefined struct
within the SessionHandle, but since we sometimes alter that option
during a request we need to have it on a per-connection basis.

I also moved more "init conn" code into the allocate_conn() function
which is designed for that purpose more or less.

As this function uses return code 0 to mean that there is no timeout, it
needs to check that it doesn't return a time left value that is exactly
zero. It could lead to libcurl doing an extra 1000 ms select() call and
thus not timing out as accurately as it should.

I fell over this bug when working on the bug 3061535 but this fix does
not correct that problem alone, although this is a problem that needs to
be fixed.

Reported by: Rodric Glaser
Bug: http://curl.haxx.se/bug/view.cgi?id=3061535

The timeout is set for the connect phase already at the start of the
request so we should not add a new one, and we MUST not set expire to 0
as that will remove any other potentially existing timeouts.

Curl_getconnectinfo() is changed to return a proper curl_socket_t for
the last socket so that it'll work more portably (and cause less
compiler warnings).

The correctly extracted errno contents were mistakenly overwritten by a newer
value that wasn't the correct error value.

Bug: http://curl.haxx.se/mail/lib-2010-08/0242.html

When the progress callback is called during the TCP connection, an error
return would accidentally not abort the operation as intended but would
instead be counted as a failure to connect to that particular IP and
libcurl would just continue to try the next. I made singleipconnect()
and trynextip() return CURLcode properly.

Added bonus: it corrected the error code for bad --interface usages,
like tested in test 1084 and test 1085.

Reported by: Adam Light
Bug: http://curl.haxx.se/mail/lib-2010-08/0105.html

When a hostname resolves to multiple IP addresses and the first one
tried doesn't work, the socket for the second attempt may get dropped on
the floor, causing the request to eventually time out. The issue is that
when using kqueue (as on mac and bsd platforms) instead of select, the
kernel removes the first fd from kqueue when it is closed (in trynextip,
connect.c:503). Trynextip() then goes on to open a new socket, which
gets assigned the same number as the one it just closed. Later in
multi.c, socket_cb is not called because the fd is already in
multi->sockhash, so the new socket is never added to kqueue.

The correct fix is to ensure that socket_cb is called to remove the fd
when trynextip() closes the socket, and again to re-add it after
singleipsocket(). I'm not sure how to cleanly do that, but the attached
patch works around the problem in an admittedly kludgy way by delaying
the close to ensure that the newly-opened socket gets a different fd.

Daniel's added comment: I didn't spot a way to easily do a nicer fix so
I've proceeded with Ben's patch.

Bug: http://curl.haxx.se/bug/view.cgi?id=3017819
Patch by: Ben Darnell