- Aug 14, 2017
-
-
Daniel Stenberg authored
... converted from the MS specific _snscanf()
-
- Aug 13, 2017
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Sergei Nikulov authored
Closes #1719
-
Daniel Stenberg authored
Fixes #1764 Closes #1773 Reported-by: James Slaughter
-
Alex Potapenko authored
Closes #1774
-
- Aug 12, 2017
-
-
Daniel Stenberg authored
Closes #1772
-
Salah-Eddin Shaban authored
This fixes redirects to IDN URLs Fixes #1441 Closes #1762 Reported by: David Lord
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Could've prevented #1755
-
Simon Warta authored
Closes #1763
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Regression since adef394a (released in 7.55.0) Reported-by: Han Qiao Fixes #1769 Closes #1771
-
Daniel Stenberg authored
Fixes #1752
-
Alessandro Ghedini authored
Closes #1770
-
Alessandro Ghedini authored
-
Alessandro Ghedini authored
-
Dan Fandrich authored
-
- Aug 11, 2017
-
-
Thomas Petazzoni authored
The long list of architectures in include/curl/system.h is annoying to maintain, and needs to be extended for each and every architecture to support. Instead, let's rely on the __SIZEOF_LONG__ define of the gcc compiler (we are in the GNUC condition anyway), which tells us if long is 4 bytes or 8 bytes. This fixes the build of libcurl 7.55.0 on architectures such as OpenRISC or ARC. Closes #1766 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Daniel Stenberg authored
Suspicion: when we enabled the threaded resolver by default.
-
Daniel Stenberg authored
-
Even Rouault authored
Fixes the below leak: $ valgrind --leak-check=full ~/install-curl-git/bin/curl --proxy "http://a:b@/x" http://127.0.0.1 curl: (5) Couldn't resolve proxy name ==5048== ==5048== HEAP SUMMARY: ==5048== in use at exit: 532 bytes in 12 blocks ==5048== total heap usage: 5,288 allocs, 5,276 frees, 445,271 bytes allocated ==5048== ==5048== 2 bytes in 1 blocks are definitely lost in loss record 1 of 12 ==5048== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5048== by 0x4E6CB79: parse_login_details (url.c:5614) ==5048== by 0x4E6BA82: parse_proxy (url.c:5091) ==5048== by 0x4E6C46D: create_conn_helper_init_proxy (url.c:5346) ==5048== by 0x4E6EA18: create_conn (url.c:6498) ==5048== by 0x4E6F9B4: Curl_connect (url.c:6967) ==5048== by 0x4E86D05: multi_runsingle (multi.c:1436) ==5048== by 0x4E88432: curl_multi_perform (multi.c:2160) ==5048== by 0x4E7C515: easy_transfer (easy.c:708) ==5048== by 0x4E7C74A: easy_perform (easy.c:794) ==5048== by 0x4E7C7B1: curl_easy_perform (easy.c:813) ==5048== by 0x414025: operate_do (tool_operate.c:1563) ==5048== ==5048== 2 bytes in 1 blocks are definitely lost in loss record 2 of 12 ==5048== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5048== by 0x4E6CBB6: parse_login_details (url.c:5621) ==5048== by 0x4E6BA82: parse_proxy (url.c:5091) ==5048== by 0x4E6C46D: create_conn_helper_init_proxy (url.c:5346) ==5048== by 0x4E6EA18: create_conn (url.c:6498) ==5048== by 0x4E6F9B4: Curl_connect (url.c:6967) ==5048== by 0x4E86D05: multi_runsingle (multi.c:1436) ==5048== by 0x4E88432: curl_multi_perform (multi.c:2160) ==5048== by 0x4E7C515: easy_transfer (easy.c:708) ==5048== by 0x4E7C74A: easy_perform (easy.c:794) ==5048== by 0x4E7C7B1: curl_easy_perform (easy.c:813) ==5048== by 0x414025: operate_do (tool_operate.c:1563) Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2984 Credit to OSS Fuzz for discovery Closes #1761
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
A gcc7 warning.
-
David Benjamin authored
Just making the pointer as const works for the pre-1.1.0 path too. Closes #1759
-
- Aug 10, 2017
-
-
Daniel Stenberg authored
To avoid "old crap" unintentionally getting shipped. Bug: https://curl.haxx.se/mail/lib-2017-08/0050.html Reported-by: Christian Weisgerber
-
Jay Satiro authored
- Enable execute permission (chmod +x) - Change interpreter to /usr/bin/env perl Ref: https://github.com/curl/curl/issues/1743
-
Daniel Stenberg authored
Closes #1647
-
Daniel Stenberg authored
Closes #1756
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Fixes #1755
-
Daniel Stenberg authored
Help-by: Jay Satiro Closes #1753
-
Marcel Raad authored
Visual Studio doesn't like LF line endings in solution files and always converts them to CRLF when doing changes to the solution. Notably, this affects the solutions in the release archive. Closes https://github.com/curl/curl/pull/1746
-
Marcel Raad authored
This folder is generated when using the CMake build system from within Visual Studio. Closes https://github.com/curl/curl/pull/1746
-
Jay Satiro authored
Bug: https://github.com/curl/curl/issues/1685 Reported-by: <paulharris@users.noreply.github.com> Assisted-by: Isaac Boukris Closes https://github.com/curl/curl/pull/1742
-
- Aug 09, 2017
-
-
Adam Sampson authored
These weren't included in the 7.55.0 release, but are required in order to run the full test suite. Closes #1744
-
Adam Sampson authored
The fix for this in 8661a0aacc01492e0436275ff36a21734f2541bb wasn't complete: if the parsed number in num is larger than will fit in a long, the conversion is undefined behaviour (causing test1427 to fail for me on IA32 with GCC 7.1, although it passes on AMD64 and ARMv7). Getting rid of the cast means the comparison will be done using doubles. It might make more sense for the max argument to also be a double... Fixes #1750 Closes #1749
-
Daniel Stenberg authored
-