... reuses the same dynamic buffer instead of doing repeated malloc/free
cycles.
Test case 100 (FTP dir list PASV) does 7 fewer memory allocation calls
after this change in my test setup (132 => 125), curl 7.72.0 needed 140
calls for this.
Test case 103 makes 9 less allocations now (130). Down from 149 in
7.72.0.
Closes#6004
... by introducing a printf() function that appends directly into a
dynbuf: Curl_dyn_vprintf(). This avoids the mandatory extra malloc so if
the buffer is already big enough it can just printf directly into it.
Since this less-malloc version requires tthe use of a library internal
printf function, we only provide this version when building libcurl and
not for the dynbuf code that is used when building the curl tool.
Closes#5998
... as that counter is subsequently used to detect if nothing was
returned from the peer. This made curl return CURLE_OK when it should
have returned CURLE_GOT_NOTHING.
Fixes#5992
Reported-by: Tom van der Woerdt
Closes#5994
Fixed two return code mixups. CURLE_UNKNOWN_OPTION is saved for when the
option is, yeah, not known. Clarified this in the setopt man page too.
Closes#5993
These two files were always tightly connected and it was hard to
understand what went into which. This also allows us to make the
ftpsend() function static (moved from ftp.c).
Removed security.c
Renamed curl_sec.h to krb5.h
Closes#5987
By avoiding an unnecessary error check and the temp use of the tm
struct, the time2epoch conversion function gets a little bit faster.
When repeating test 517, the updated version is perhaps 1% faster (on
one particular build on one particular architecture).
Closes#5985
Remove the text saying
"the curl cmake build system is poorly maintained. Be aware"
... not because anything changed just now, but to encourage users to use
it and subsequently improve it.
Closes#5984
This document is not maintained and rather than trying to refresh it,
let's kill it. A more up-to-date document with relevant RFCs is this
page on the curl website: https://curl.haxx.se/rfc/Closes#5980
Makes it easier to browse on github etc. Offers (better) links.
It should be noted that this document is already mostly outdated and
"Everything curl" at https://ec.haxx.se/ is a better resource and
tutorial.
Closes#5981
... since it is converted and the original pointer is freed on Windows
unicode handling.
Follow-up to aa8777f63fFixes#5977Closes#5978
Reported-by: xwxbug on github
If the received PASV response doesn't match the expected pattern, we
could end up reading uninitialized integers for IP address and port
number.
Issue pointed out by muse.dev
Closes#5972
Since HTTPS is "the new normal", this update changes a lot of man page
examples to use https://example.com instead of the previous "http://..."
Closes#5969
Also skip pre-checking sockets to set timeout_ms to 0
after the first socket has been detected to be ready.
Reviewed-by: rcombs on github
Reviewed-by: Daniel Stenberg
Follow up to #5886
Since the struct is quite large (1 long and 10 ints) we
declare it once at the beginning of the function instead
of multiple times inside loops to avoid stack movements.
Reviewed-by: Viktor Szakats
Reviewed-by: Daniel Stenberg
Closes#5886
When the code was changed to do fputs() instead of fprintf() it got
sensitive for NULL pointers; add checks for that.
Follow-up from 0c1e767e83Closes#5963
This is primarily interesting for cases where CURLOPT_NOBODY is set as
previously curl would not return an error for this case.
MDTM getting 550 now also returns this error (it returned
CURLE_FTP_COULDNT_RETR_FILE before) in order to unify return codes for
missing files across protocols and specific FTP commands.
libcurl already returns error on a 550 as a MDTM response (when
CURLOPT_FILETIME is set). If CURLOPT_NOBODY is not set, an error would
happen subsequently anyway since the RETR command would fail.
Add test 1913 and 1914 to verify. Updated several tests accordingly due
to the updated SIZE behavior.
Reported-by: Tomas Berger
Fixes#5953Closes#5957
... when continuing a transfer from a FETCH response.
When the size of the file was small enough that the entirety of the
transfer happens in a single go and schannel buffers holds the entire
data. However, it wasn't completely read in Curl_pp_readresp since a
line break was found before that could happen. So, by the time we are in
imap_state_fetch_resp - there's data in buffers that needs to be read
via Curl_read but nothing to read from the socket. After we setup a
transfer (Curl_setup_transfer), curl just waits on the socket state to
change - which doesn't happen since no new data ever comes.
Closes#5961
