We use `check_c_source_compiles` to check possible send/recv signatures
by reproducing the forward declarations from system headers. On Windows
the `winsock2.h` header adds dll linkage settings to its forward
declaration. If ours does not match the compiler warns:
warning C4273: 'recv': inconsistent dll linkage
Add `WINSOCK_API_LINKAGE` to our test signatures when it is defined so
that our linkage is consistent with that from `winsock2.h`.
Fixes#4764Closes#5232
To avoid collision risks with private libcurl symbols when linked with
static versions (or just versions not hiding internal symbols).
Reported-by: hydra3333 on github
Fixes#5219Closes#5234
The tests changed from ignored to disabled are tests that are
about connecting to non-listening socket. On AppVeyor these
tests are not reliable, because for some unknown reason the
connect is not timing out before the test time limit is reached.
- Fix schannel_send for the case when no timeout was set.
Prior to this change schannel would error if the socket was not ready
to send data and no timeout was set.
This commit is similar to parent commit 89dc6e0 which recently made the
same change for SOCKS, for the same reason. Basically it was not well
understood that when Curl_timeleft returns 0 it is not a timeout of 0 ms
but actually means no timeout.
Fixes https://github.com/curl/curl/issues/5177
Closes https://github.com/curl/curl/pull/5221
- Document in Curl_timeleft's comment block that returning 0 signals no
timeout (ie there's infinite time left).
- Fix SOCKS' Curl_blockread_all for the case when no timeout was set.
Prior to this change if the timeout had a value of 0 and that was passed
to SOCKET_READABLE it would return right away instead of blocking. That
was likely because it was not well understood that when Curl_timeleft
returns 0 it is not a timeout of 0 ms but actually means no timeout.
Ref: https://github.com/curl/curl/pull/5214#issuecomment-612512360
Closes https://github.com/curl/curl/pull/5220
Prior to this change gopher's blocking code would block forever,
ignoring any set timeout value.
Assisted-by: Jay Satiro
Reviewed-by: Daniel Stenberg
Similar to #5220 and #5221Closes#5214
When SRP is requested in the priority string, GnuTLS will disable
support for TLS 1.3. Before this change, curl would always add +SRP to
the priority list, effectively always disabling TLS 1.3 support.
With this change, +SRP is only added to the priority list when SRP
authentication is also requested. This also allows updating the error
handling here to not have to retry without SRP. This is because SRP is
only added when requested and in that case a retry is not needed.
Closes#5223
Since the Windows versions of both programs would write Windows
PIDs to their pidfiles which we cannot handle, we need to use
our known perl.exe Cygwin/msys PID together with exec() in order
to tie the spawned processes to the existance of our perl.exe
The perl.exe that is executing secureserver.pl and sshserver.pl
has a Cygwin/msys PID, because it is started inside Cygwin/msys.
Related to #5188
- If loss of data may occur converting a timediff_t to time_t and
the time value is > TIME_T_MAX then treat it as TIME_T_MAX.
This is a follow-up to 8843678 which removed the (time_t) typecast
from the macros so that conversion warnings could be identified.
Closes https://github.com/curl/curl/pull/5199
- Ignore intermediate progress updates.
- Support locales that use a character other than period as decimal
separator (eg 100,0%).
test1148 checks that the progress finishes at 100% and has the right
bar width. Prior to this change the test assumed that the only progress
reported for such a quick transfer was 100%, however in rare instances
(like in the CI where transfer time can slow considerably) there may be
intermediate updates. For example, below is stderrlog1148 from a failed
CI run with explicit \r and \n added (it is one line; broken up so that
it's easier to understand).
\r
\r################################## 48.3%
\r######################################################################## 100.0%
\n
Closes https://github.com/curl/curl/pull/5194
With this bit set, my mac successfully resolves "ip6-localhost" when in
fact there is no such host known to my machine! That in turn made test
241 wrongly execute and fail.
Closes#5202
