Function Curl_bufref_ptr() now returns a const char *.
New function Curl_bufref_uptr() returns a const unsigned char *.
Usage and doc updated.
Closes#19827
OpenSSL 4 has plans to make ASN1_STRING opaque, which will break the
build, so convert the code to use accessors. ASN1_STRING_length() and
ASN1_STRING_type() go way back to SSLeay and ASN1_STRING_get0_data() is
OpenSSL 1.1 API present in BoringSSL since foreer and also available
since LibreSSL 2.7, so this should not cause compat issues with any
libcrypto in a supported version of the fork family.
https://github.com/openssl/openssl/issues/29117Closes#19831
Eliminate a heap buffer in both `win32_idn_to_ascii()` and
`win32_ascii_to_idn()`, by replacing it with stack buffer. The maximum
size is fixed in these cases, and small enough to fit there.
Also reuse length returned by the UTF-8 to wchar conversion, allowing
to drop `wcslen()` call in both functions, and allowing to call
the wchar to UTF-8 conversion API `WideCharToMultiByte()` with the known
length, saving length calculations within that API too.
Ref: https://github.com/curl/curl/pull/19748#issuecomment-3592015200Closes#19798
A fix for the tests that took the longest:
- test_05: make the server close the HTTP/1.1 connection when
simulating an error during a download. This eliminates waiting
for a keepalive timeout
- test_02: pause tests with slightly smaller documents, eliminate
special setup for HTTP/2. We test stream window handling now
elsewhere already
- cli_hx_download: run look in 500ms steps instead of 1sec, resuming
paused tranfers earlier.
Closes#19809
Instead of buffering response body data until it is received by the
transfer loop, write the response data directly to the client.
Use a connection wide scratch buffer to get the response body from
quiche. Eliminates need for maintaining individual buffers for each
stream.
Fixes#19803
Reported-by: Stanislav Fort
Closes#19806
add the debug log before freeing the memory, otherwise another thread
might allocate and log it before the free is logged.
Follow-up to a7bebd8502Closes#19787
Protect modification to the `membuf` by different threads
via a mutex. This ensure that index updates are correct and
that data gets written in order.
Closes#19785
Use the already detected `gssapi/gssapi_krb5.h` MIT Kerberos header
to pull in `gssapi_ext.h`, which in turn sets `GSS_C_CHANNEL_BOUND_FLAG`
if supported. Channel binding is present in MIT Kerberos 1.19+.
Also:
- lib: de-duplicate GSS-API header includes.
- vauth: de-duplicate `urldata.h` includes.
- drop interim feature macro in favor of the native GSS one.
Assisted-by: Max Faxälv
Reported-by: Max Faxälv
Bug: https://github.com/curl/curl/pull/19164#issuecomment-3551687025
Follow-up to 8616e5aada#19164Closes#19603Closes#19760
Follow-up to c1e3a760b. The previous update missed an addition that also
can wrap and cause confusion. Fixing this by calling
Curl_pgrsSetDownloadSize() after the overflow check.
Reported-by: Deniz Parlak
Closes#19774
The macro is present in all supported Windows toolchains.
It's present in mingw-w64 v3+, and in MS SDK 6.0A+ (maybe earlier).
Also:
- restrict this logic to `USE_WINSOCK` (was: `_WIN32`), to exclude
alternate socket libraries (i.e. lwIP). lwIP supports `IPV6_V6ONLY`
since its 2.0.0 (2016-11-10) release and it's disabled by default,
unlike in Winsock.
Ref: e65202f825
- delete interim setter function/dummy macro `set_ipv6_v6only()`.
Follow-up to a28f5f68b9#18010
Follow-up to ca3f6decb9#10975Closes#19769
Before this patch it added Windows-specific casts. In unity builds this
also affected other source files.
`setsockopt()` is called without special casts in other places in
the code, and passing a non-const char ptr to a const char ptr arg also
should work.
Basic compile test with mingw-w64 confirms. In case of issues, a cast to
`curl_socklen_t` can be used, or do the special case in an `#if` branch.
Also: merge Windows-specific guards for `SET_RCVTIMEO()`.
Follow-up to 639d052e44#3155
Follow-up to 04cb15ae9dCloses#19768
Since this function returns allocated resources there is probably at
least a theoretical risk this can return NULL.
Pointed out by ZeroPath
Closes#19756
To fix non-unity builds using certain header orders (seen in ntlm.c with
the include order changed):
```
lib/vauth/../sendf.h:117:27: error: ‘struct Curl_cwriter’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
117 | struct Curl_cwriter *writer);
| ^~~~~~~~~~~~
lib/vauth/../sendf.h:215:54: error: ‘struct Curl_creader’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
215 | CURLcode (*do_init)(struct Curl_easy *data, struct Curl_creader *reader);
| ^~~~~~~~~~~~
[...]
```
Ref: https://github.com/curl/curl/actions/runs/19785420705/job/56691185397?pr=19760
Ref: #19760Closes#19761
Rework the way curl's custom Find modules advertise their properties.
Before this patch, Find modules returned detected dependency properties
(header dirs, libs, libdirs, C flags, etc.) via global variables. curl's
main `CMakeLists.txt` copied their values into global lists, which it
later applied to targets. This solution worked internally, but it was
unsuited for the public, distributed `CURLConfig.cmake` and publishing
curl's Find modules with it, due to polluting the namespace of consumer
projects. It's also impractical to apply the many individual variables
to every targets depending on libcurl.
To allow using Find modules in consumer projects, this patch makes them
define as imported interface targets, named `CURL::<dependency>`. Then
store dependency information as target properties. It avoids namespace
pollution and makes the dependency information apply automatically
to all targets using `CURL::libcurl_static`.
Find modules continue to return `*_FOUND` and `*_VERSION` variables.
For dependencies detected via `pkg-config`, CMake 3.16+ is recommended.
Older CMake versions have a varying degree of support for
propagating/handling library directories. This may cause issues in envs
where dependencies reside in non-system locations and detected via
`pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF`
to fix these issues. Or upgrade to newer CMake, or link libcurl
dynamically.
Also:
- re-enable `pkg-config` for old cmake `find_library()` integration
tests.
- make `curlinfo` build after these changes.
- distribute local Find modules.
- export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`.
- `CURLconfig.cmake`: use curl's Find modules to detect dependencies in
the consumer env.
- add custom property to target property debug function.
- the curl build process no longer modifies `CMAKE_C_FLAGS`.
Follow-up to e86542038d#17047
Ref: #14930
Ref: https://github.com/libssh2/libssh2/pull/1535
Ref: https://github.com/libssh2/libssh2/pull/1571
Ref: https://github.com/libssh2/libssh2/pull/1581
Ref: https://github.com/libssh2/libssh2/pull/1623Closes#16973
Instead of writing each line to file immediately, this now stores them
in an in-memory buffer until that gets full or curl exits. To make it
run faster and write to file less often.
Closes#19750
To conclude changing the send buffer type from `const void *` to `const
uint8_t *`, change the top level send function and its implementations.
Closes#19743
Remove connection member `waitfor` and keep it in the SSH connection
meta. Add `ssh` to supported tracing features, convert many DEBUGF
printgs to traces.
Closes#19745
Before this patch curl used the C preprocessor to override standard
memory allocation symbols: malloc, calloc, strdup, realloc, free.
The goal of these is to replace them with curl's debug wrappers in
`CURLDEBUG` builds, another was to replace them with the wrappers
calling user-defined allocators in libcurl. This solution needed a bunch
of workarounds to avoid breaking external headers: it relied on include
order to do the overriding last. For "unity" builds it needed to reset
overrides before external includes. Also in test apps, which are always
built as single source files. It also needed the `(symbol)` trick
to avoid overrides in some places. This would still not fix cases where
the standard symbols were macros. It was also fragile and difficult
to figure out which was the actual function behind an alloc or free call
in a specific piece of code. This in turn caused bugs where the wrong
allocator was accidentally called.
To avoid these problems, this patch replaces this solution with
`curlx_`-prefixed allocator macros, and mapping them _once_ to either
the libcurl wrappers, the debug wrappers or the standard ones, matching
the rest of the code in libtests.
This concludes the long journey to avoid redefining standard functions
in the curl codebase.
Note: I did not update `packages/OS400/*.c` sources. They did not
`#include` `curl_setup.h`, `curl_memory.h` or `memdebug.h`, meaning
the overrides were never applied to them. This may or may not have been
correct. For now I suppressed the direct use of standard allocators
via a local `.checksrc`. Probably they (except for `curlcl.c`) should be
updated to include `curl_setup.h` and use the `curlx_` macros.
This patch changes mappings in two places:
- `lib/curl_threads.c` in libtests: Before this patch it mapped to
libcurl allocators. After, it maps to standard allocators, like
the rest of libtests code.
- `units`: before this patch it mapped to standard allocators. After, it
maps to libcurl allocators.
Also:
- drop all position-dependent `curl_memory.h` and `memdebug.h` includes,
and delete the now unnecessary headers.
- rename `Curl_tcsdup` macro to `curlx_tcsdup` and define like the other
allocators.
- map `curlx_strdup()` to `_strdup()` on Windows (was: `strdup()`).
To fix warnings silenced via `_CRT_NONSTDC_NO_DEPRECATE`.
- multibyte: map `curlx_convert_*()` to `_strdup()` on Windows
(was: `strdup()`).
- src: do not reuse the `strdup` name for the local replacement.
- lib509: call `_strdup()` on Windows (was: `strdup()`).
- test1132: delete test obsoleted by this patch.
- CHECKSRC.md: update text for `SNPRINTF`.
- checksrc: ban standard allocator symbols.
Follow-up to b12da22db1#18866
Follow-up to db98daab05#18844
Follow-up to 4deea9396b#18814
Follow-up to 9678ff5b1b#18776
Follow-up to 10bac43b87#18774
Follow-up to 20142f5d06#18634
Follow-up to bf7375ecc5#18503
Follow-up to 9863599d69#18502
Follow-up to 3bb5e58c10#17827Closes#19626
