Older unixes want an 'int' instead of 'size_t' as the 3rd argumment so before this change it would cause warnings such as: There is an implicit conversion from "unsigned long" to "int"; rounding, sign extension, or loss of accuracy may result.
Signed-off-by: Diego Casorran <email@example.com>
Was seeing spurious SSL connection aborts using libcurl and OpenSSL. I tracked it down to uncleared error state on the OpenSSL error stack - patch attached deals with that. Rough idea of problem: Code that uses libcurl calls some library that uses OpenSSL but don't clear the OpenSSL error stack after an error. ssluse.c calls SSL_read which eventually gets an EWOULDBLOCK from the OS. Returns -1 to indicate an error ssluse.c calls SSL_get_error. First thing, SSL_get_error calls ERR_get_error to check the OpenSSL error stack, finds an old error and returns SSL_ERROR_SSL instead of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. ssluse.c returns an error and aborts the connection Solution: Clear the openssl error stack before calling SSL_* operation if we're going to call SSL_get_error afterwards. Notes: This is much more likely to happen with multi because it's easier to intersperse other calls to the OpenSSL library in the same thread.
Enable OpenLDAP support for cygwin builds. This support was disabled back in 2008 due to incompatibilities between OpenSSL and OpenLDAP headers. cygwin's OpenSSL 0.9.8l and OpenLDAP 2.3.43 versions on cygwin 1.5.25 allow building an OpenLDAP enabled libcurl supporting back to Windows 95. Remove non-functional CURL_LDAP_HYBRID code and references.
Jason McDonald posted bug report #3006786 when he found that the SFTP code didn't timeout properly in several places in the code even if a timeout was set properly. Based on his suggested patch, I wrote a different implementation that I think addressed the issue better and also uses the connect timeout for the initial part of the SSH/SFTP done during the "protocol connect" phase. (http://curl.haxx.se/bug/view.cgi?id=3006786)
Igor Novoseltsev reported a problem with the multi socket API and using timeouts and timers. It boiled down to a problem with libcurl's use of GetTickCount() interally to figure out the current time, while Igor's own application code used another function call. It made his app call the socket API timeout function a bit _before_ libcurl would consider the timeout to trigger, and that could easily lead to timeouts or stalls in the app. It seems GetTickCount() in general often has no better resolution than 16ms and switching to the alternative function QueryPerformanceCounter has its share of problems: http://www.virtualdub.org/blog/pivot/entry.php?id=106 We address this problem by simply having libcurl treat timers that already has occured or will occur within 40ms subject for treatment. I'm confident that there are other implementations and operating systems with similarly in accurate timer functions so it makes sense to have applied generically and I don't believe we sacrifice much by adding a 40ms inaccuracy on these timeouts.