Make autotools and cmake detect DES support in OpenSSL and mbedTLS.
Forward feature macros to C and omit NTLM from the feature preview list.
Use the feature macros in source. This ensure that `-V` output matches
the preview.
OpenSSL doesn't support DES when built with `no-des` or `no-deprecated`.
mbedTLS 4.x no longer supports it, and it's possible to disable it in
<4 with `scripts/config.py unset MBEDTLS_DES_C`.
Before this patch this worked for
mbedTLS 4 only, and with a regression for pending PR #16973.
Also:
- drop NTLM feature check from `curl_setup.h` in favour of autotools/
cmake feature macros. This makes `curl_setup.h` no longer need
to include an mbedTLS header, which in turn makes tests/server build
without depending on mbedTLS.
Fixing, in #16973:
```
In file included from tests/server/first.h:40,
from bld/tests/server/servers.c:3:
lib/curl_setup.h:741:10: fatal error: mbedtls/version.h: No such file or directory
741 | #include <mbedtls/version.h>
| ^~~~~~~~~~~~~~~~~~~
```
Ref: https://github.com/curl/curl/actions/runs/18689537893/job/53291322012?pr=16973
Ref: #19181 (initial fix idea)
Follow-up to 3a305831d1#19077
- move back mbedTLS header include and version check from
`curl_setup.h` to each source which consumes mbedTLS.
- GHA/http3-linux: drop workaround that disabled NTLM for
`no-deprecated` OpenSSL builds.
Follow-up to 006977859d#12384
- curl_ntlm_core: drop pointless macro `CURL_NTLM_NOT_SUPPORTED`.
Follow-up to 006977859d#12384Closes#19206
After this patch, the codebase no longer overrides system printf
functions. Instead it explicitly calls either the curl printf functions
`curl_m*printf()` or the system ones using their original names.
Also:
- drop unused `curl_printf.h` includes.
- checksrc: ban system printf functions, allow where necessary.
Follow-up to db98daab05#18844
Follow-up to 4deea9396b#18814Closes#18866
Also:
- tests/server: replace local `sstrerror()` with `curlx_strerror()`.
- tests/server: show the error code next to the string, where missing.
- curlx: use `curl_msnprintf()` when building for src and tests.
(units was already using it.)
- lib: drop unused includes found along the way.
- curlx_strerror(): avoid compiler warning (and another similar one):
```
In file included from servers.c:14:
../../lib/../../lib/curlx/strerr.c: In function ‘curlx_strerror’:
../../lib/../../lib/curlx/strerr.c:328:32: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
328 | SNPRINTF(buf, buflen, "%s", msg);
| ^
../../lib/../../lib/curlx/strerr.c:47:18: note: ‘snprintf’ output 1 or more bytes (assuming 2) into a destination of size 1
47 | #define SNPRINTF snprintf
| ^
../../lib/../../lib/curlx/strerr.c:328:7: note: in expansion of macro ‘SNPRINTF’
328 | SNPRINTF(buf, buflen, "%s", msg);
| ^~~~~~~~
```
Follow-up to 45438c8d6f#18823Closes#18840
Replace them by `curlx_open()` and `curlx_stat()`.
To make it obvious in the source code what is being executed.
Also:
- tests/server: stop overriding `open()` for test servers.
This is critical for the call made from the signal handler.
For other calls, it's an option to use `curlx_open()`, but
doesn't look important enough to do it, following the path
taken with `fopen()`.
Follow-up to 10bac43b87#18774
Follow-up to 20142f5d06#18634
Follow-up to bf7375ecc5#18503Closes#18776
By introducing wrappers for them in the curlx namespace:
`curlx_fopen()`, `curlx_fdopen()`, `curlx_fclose()`.
The undefine/redefine/`(function)()` methods broke on systems
implementing these functions as macros. E.g. AIX 32-bit's `fopen()`.
Also:
- rename `lib/fopen.*` to `lib/curl_fopen.*` (for `Curl_fopen()`)
to make room for the newly added `curlx/fopen.h`.
- curlx: move file-related functions from `multibyte.c` to `fopen.c`.
- tests/server: stop using the curl-specific `fopen()` implementation
on Windows. Unicode isn't used by runtests, and it isn't critical to
run tests on longs path. It can be re-enabled if this becomes
necessary, or if the wrapper receives a feature that's critical for
test servers.
Reported-by: Andrew Kirillov
Bug: https://github.com/curl/curl/issues/18510#issuecomment-3274393640
Follow-up to bf7375ecc5#18503
Follow-up to 9863599d69#18502
Follow-up to 3bb5e58c10#17827Closes#18634
The implementation was incomplete and lesser than the other backends. No
one ever reported a bug or requested enhancements for this, indicating
that this backend was never used.
Closes#18700
Before this patch `accept4()`, `socket()`, `socketpair()`, `send()` and
`recv()` system symbols were remapped via macros, using the same name,
to local curl debug wrappers. This patch replaces these overrides by
introducing curl-namespaced macros that map either to the system symbols
or to their curl debug wrappers in `CURLDEBUG` (TrackMemory) builds.
This follows a patch that implemented the same for `accept()`.
The old method required tricks to make these redefines work in unity
builds, and avoid them interfering with system headers. These tricks
did not work for system symbols implemented as macros.
The new method allows to setup these mappings once, without interfering
with system headers, upstream macros, or unity builds. It makes builds
more robust.
Also:
- checksrc: ban all mapped functions.
- docs/examples: tidy up checksrc rules.
Follow-up to 9863599d69#18502
Follow-up to 3bb5e58c10#17827Closes#18503
To avoid hitting `-Wreserved-macro-identifier` where possible.
- amigaos: introduce local macro instead of reusing `__request()`.
- easy_lock: avoid redefining `__has_builtin()`.
Follow-up to 33fd57b8ff#9062
- rand: drop interim macro `_random()`.
- windows: rename local macro `_tcsdup()` to `Curl_tcsdup()`.
To avoid using the reserved macro namespace and to avoid
colliding with `_tcsdup()` as defined by Windows headers.
- checksrc: ban `_tcsdup()` in favor of `Curl_tcsdup()`.
- tool_doswin: avoid redefining `_use_lfn()` (MS-DOS).
- tool_findfile: limit `__NO_NET_API` hack to AmigaOS.
Syncing this pattern with `lib/netrc.c`.
Follow-up to 784a8ec2c1#16279
- examples/http2-upload: avoid reserved namespace for local macro.
More cases will be removed when dropping WinCE support via #17927.
Cases remain when defining external macros out of curl's control.
Ref: #18477Closes#18482
To avoid overriding the system symbol `accept`, which is a macro on some
systems (AIX), and thus can't be called via the `(function)` PP trick.
It's also problematic to reset such macro to its original value.
Follow-up to 3bb5e58c10#17827
Reported-by: Andrew Kirillov
Fixes#18500Closes#18501Closes#18502
Added in 2011, but has seen little use in the code. The necessary
compiler feature is missing in some compilers (e.g. MSVC), thus in most
places the portable `(void)` cast is used in addition.
Also:
- vtls/rustls: silence unused argument warning with `(void)`.
Necessary for MSVC, for example.
Ref: ee4ed46128Closes#18455
In WebAssembly, using `TCP_NODELAY` fails with:
```
* Could not set TCP_NODELAY: Protocol not available
```
Add a new feature macro in `curl_setup.h` telling whether `TCP_NODELAY`
is known to be supported at runtime, when defined at compile-time.
Keep `TCP_NODELAY` guards at their current positions to ensure the
necessary headers (e.g. `netinet/tcp.h` and `netinet/in.h`) define it.
Reported-by: Jeroen Ooms
Fixes#17974Closes#18155
Early mingw-w64 releases missed it, but by requiring v3.0, this is no
longer an issue. Supported Visual Studio SDKs also offer it.
Follow-up to a28f5f68b9#18010Closes#18057
Fixing:
- HTTPS-RR builds with c-ares and Linux MUSL.
- curl-for-win minimal builds with Linux MUSL.
It should fix all other kinds of entaglement between curl's redefintions
of system symbols and system (or 3rd-party) headers sensitive to that.
It also syncs memory override behavior between unity & non-unity builds,
thus reducing build variations.
The idea is to define and declare everything once in `curl_setup.h`,
without overriding any system symbols with curl ones yet. Then, like
before this patch, override them, if necessary, in each source file via
`curl_memory.h` and `memdebug.h`, after including system headers.
To ensure a clean slate with no overrides at the beginning of each
source file, reset all of them unconditionally at the end of
`curl_setup.h`, by including `curl_mem_undef.h`. (This assumes
`curl_setup.h` is always included first, which is already the case
throughout the codebase.)
`curl_mem_undef.h` can also be included explicitly wherever overrides
are causing problems. E.g. in tests which use unity-style builds and
a previously included `curl_memory.h`/`memdebug.h` can be spilling into
other source files.
The simplified role of the two override headers:
- `curl_memory.h`: overrides system memory allocator functions to
libcurl ones, when memory tracing (aka `CURLDEBUG`) is disabled.
- `memdebug.h`: overrides system memory allocator and some other
functions to curl debug functions, when memory tracing is enabled.
Changed made in this patch, step-by-step:
- curl_memory.h: move allocator typedefs and protos to `curl_setup.h`.
- memdebug.h: move `ALLOC_*` macros to `curl_setup.h`.
- memdebug.h: move allocator protos to `curl_setup.h`.
- memdebug.h: move `Curl_safefree()` macro to `curl_setup.h`.
(it's a regular macro, with a one-time, global, definition.)
- curl_memory.h: move system symbol undefs to a new, separate header:
`curl_mem_undef.h`.
- curl_setup.h: include `curl_mem_undef.h` at the end, unconditionally,
to reset system symbol macros after each inclusion.
- handle `sclose()` and `fake_sclose()` in `curl_setup.h`. They are not
system symbols, a one-time definition does the job.
Also:
- GHA/linux: enable unity mode for the HTTP-RR c-ares MUSL job.
Follow-up to 17ab4d62e6#16413
That said, I'd still find it better to avoid redefining system macros.
To communicate clearly the fact that they are not the original system
calls and they do behave differently. And, it would allow dropping the
undef/redef dance in each source file, and maintaining the logic with
it. The "last #include files should be in this order" comments in each
source would also become unnecessary. Also the trick of using
`(func)` (or interim macros) to call the non-overridden function where
required. This method works for printf and most everything else already.
For `_tcsdup`, socket and fopen functions this could work without
disturbing the codebase much.
Ref: #16428 (clean reboot of)
Closes#17827
mingw-w64 3.0 was released on 2013-09-20. Offered by Debian jessie.
1.0 and 2.0 were released in 2011. It seems unlikely that many people
use them. The oldest downloadable toolchain (that I know of) comes with
3.0. Due to this, older versions weren't CI tested, and probably seldom
tested elsewhere. The last bugfix update for both 1.0 and 2.0 was
released in 2015.
curl can now assume availability of these 3.0 features/fixes:
- 64-bit file offsets.
- `ADDRESS_FAMILY` type.
- `__MINGW_PRINTF_FORMAT` macro. (in public curl headers)
Public curl headers keep supporting older mingw-w64 versions.
Fixes#17984Closes#18010
This change wasn't good because `config-win32.h` does rely on the UWP
detection result to set `USE_WIN32_CRYPTO` and LDAP macros. While it
fixed one issue, it created another.
It seems better to revert, and focus on reducing and/or eventually
dropping the logic within `config-win32.h` that alters `_WIN32_WINNT`.
It may not be necessary anymore with a minimum of VS2008 (soon VS2010).
The logic is also absent from cmake builds, without causing issues.
Could affect UWP winbuild/project-file builds. These are theoretical
builds because neither build method is prepared to target UWP.
Reverts 792a61e204#17980
Ref: https://github.com/curl/curl/pull/17980#issuecomment-3114462492Closes#18014
Introduce an immutable `CURL_FOPEN()` macro to store the `fopen()`
mapping on Windows. Then use that instead `(fopen)` from `memdebug.c`.
It makes CURLDEBUG builds use the correct `fopen` wrapper on Windows.
This macro is only defined on Windows, as of this patch.
This is necessary after cde81e4398,
which no longer applies the default `fopen()` override to `memdebug.c`.
Also:
- curl_setup.h: de-dupe, simplify Windows file I/O function overrides.
- curl_memory.h: fix to reset `fopen` to `curlx_win32_fopen()` on
Windows. Before this patch it reset it to stock `fopen()`.
Follow-up to cde81e4398#17631Closes#16747
These libraries do not support TLS 1.3 and have been marked for removal
for over a year. We want to help users select a TLS dependency that is
future-proof and reliable, and not supporting TLS 1.3 in 2025 does not
infer confidence. Users who build libcurl are likely to be served better
and get something more future-proof with a TLS library that supports
1.3.
Closes#16677
It was not a function properly exposed in the curlx set. SMB cannot
possibly need to send a real pid, now sends a made up number.
The only real users of this function are test servers, so move the logic
over there.
Closes#17298
Move curlx_ functions into its own subdir.
The idea is to use the curlx_ prefix proper on these functions, and use
these same function names both in tool, lib and test suite source code.
Stop the previous special #define setup for curlx_ names.
The printf defines are now done for the library alone. Tests no longer
use the printf defines. The tool code sets its own defines. The printf
functions are not curlx, they are publicly available.
The strcase defines are not curlx_ functions and should not be used by
tool or server code.
dynbuf, warnless, base64, strparse, timeval, timediff are now proper
curlx functions.
When libcurl is built statically, the functions from the library can be
used as-is. The key is then that the functions must work as-is, without
having to be recompiled for use in tool/tests. This avoids symbol
collisions - when libcurl is built statically, we use those functions
directly when building the tool/tests. When libcurl is shared, we
build/link them separately for the tool/tests.
Assisted-by: Jay Satiro
Closes#17253
Enable eventfd code consistently when both `HAVE_EVENTFD` and
`HAVE_SYS_EVENTFD_H` macros are defined.
Before this patch `HAVE_EVENTFD` guarded it alone, though the code
also required the header, which was guarded by `HAVE_SYS_EVENTFD_H`.
These should normally be detected in pairs. When they aren't, omit using
`eventfd()` to avoid calling it without a known matching header.
If this disables valid cases (e.g. some system declares this function
via a different header), feature detection and the code may be extended
for those cases. If these are known to come in pairs, always, another
option is detect them both at build stage, and forward a single macro
to C.
Reported-by: Abhinav Singhal
Bug: https://curl.se/mail/lib-2025-04/0000.htmlCloses#16909
Before this patch the signal handler called `logmsg()` which in turn
called `printf()` variants (internal implementations), and `FILE *`
functions, `localtime()`. Some of these called `malloc`/`free`, which
isn't supported in s signal handler. Replace them with `write` calls,
losing some logging functionality.
Also:
- De-dupe and move `STD*_FILENO` macros to `lib/curl_setup.h`. Revert
the `src` definition to point to `stderr`, instead of `tool_stderr`.
Follow-up to e5bb88b8f8#11958
POSIX specs with list of functions allowed in a signal handler:
2004: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03
2017: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
2024: https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04_03
Linux CI run with the thread sanitizer going crazy when
hitting the signal handler in test 1238 and 1242 (TFTP):
```
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=12582)
#0 malloc <null> (servers+0x5ed70)
#1 _IO_file_doallocate <null> (libc.so.6+0x851b4)
#2 formatf /home/runner/work/curl/curl/bld/tests/server/../../lib/../../lib/mprintf.c:886:9 (servers+0xdff77)
[...]
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=12582)
#0 free <null> (servers+0x5f453)
#1 fclose <null> (libc.so.6+0x8532f)
#2 logmsg /home/runner/work/curl/curl/bld/tests/server/../../../tests/server/util.c:134:5 (servers+0xe684d)
```
Ref: https://github.com/curl/curl/actions/runs/14118903372/job/39555309490?pr=16851Closes#16852
Before this patch, standard `E*` errno codes were redefined on Windows,
onto matching winsock2 `WSA*` error codes, which have different values.
This broke uses where using the `E*` value in non-socket context, or
other places expecting a POSIX `errno`, e.g. file I/O, threads, IDN or
interfacing with dependencies.
Fix it by introducing a curl-specific `SOCKE*` set of macros that map to
`WSA*` on Windows and standard POSIX codes on other platforms. Then
verify and update the code to use `SOCKE*` or `E*` macro depending on
context.
- Add `SOCKE*` macros that map to either winsock2 or POSIX error codes.
And use them with `SOCKERRNO` or in contexts requiring
platform-dependent socket error codes.
This fixes `E*` uses which were supposed be POSIX values, not `WSA*`
socket errors, on Windows:
- lib/curl_multibyte.c
- lib/curl_threads.c
- lib/idn.c
- lib/vtls/gtls.c
- lib/vtls/rustls.c
- src/tool_cb_wrt.c
- src/tool_dirhie.c
- Ban `E*` codes having a `SOCKE*` mapping, via checksrc.
Authored-by: Daniel Stenberg
- Add exceptions for `E*` codes used in file I/O, or other contexts
requiring POSIX error codes.
Also:
- ftp: fix missing `SOCKEACCES` mapping for Windows.
- add `SOCKENOMEM` for `Curl_getaddrinfo()` via `asyn-thread.c`.
- tests/server/sockfilt: fix to set `SOCKERRNO` in local `select()`
override on Windows.
- lib/inet_ntop: fix to return `WSAEINVAL` on Windows, where `ENOSPC` is
used on other platforms. To simulate Windows' built-in `inet_ntop()`,
as tested on a Win10 machine.
Note:
- WINE returns `STATUS_INVALID_PARAMETER` = `0xC000000D`.
- Microsoft documentation says it returns `WSA_INVALID_PARAMETER`
(= `ERROR_INVALID_PARAMETER`) 87:
https://learn.microsoft.com/windows/win32/api/ws2tcpip/nf-ws2tcpip-inet_ntop#return-value
- lib/inet_ntop: drop redundant `CURL_SETERRNO(ENOSPC)`.
`inet_ntop4()` already sets it before returning `NULL`.
- replace stray `WSAEWOULDBLOCK` with `USE_WINSOCK` macro to detect
winsock2.
- move existing `SOCKE*` mappings from `tests/server` to
`curl_setup_once.h`.
- add missing `EINTR`, `EINVAL` constants for WinCE.
Follow-up to abf80aae38#16612
Follow-up to d69425ed7d#16615
Bug: https://github.com/curl/curl/pull/16553#issuecomment-2704679377Closes#16621
The issues found fell into these categories, with the applied fixes:
- const was accidentally stripped.
Adjust code to not cast or cast with const.
- const/volatile missing from arguments, local variables.
Constify arguments or variables, adjust/delete casts. Small code
changes in a few places.
- const must be stripped because an API dependency requires it.
Strip `const` with `CURL_UNCONST()` macro to silence the warning out
of our control. These happen at API boundaries. Sometimes they depend
on dependency version, which this patch handles as necessary. Also
enable const support for the zlib API, using `ZLIB_CONST`. Supported
by zlib 1.2.5.2 and newer.
- const must be stripped because a curl API requires it.
Strip `const` with `CURL_UNCONST()` macro to silence the warning out
of our immediate control. For example we promise to send a non-const
argument to a callback, though the data is const internally.
- other cases where we may avoid const stripping by code changes.
Also silenced with `CURL_UNCONST()`.
- there are 3 places where `CURL_UNCONST()` is cast again to const.
To silence this type of warning:
```
lib/vquic/curl_osslq.c:1015:29: error: to be safe all intermediate
pointers in cast from 'unsigned char **' to 'const unsigned char **'
must be 'const' qualified [-Werror=cast-qual]
lib/cf-socket.c:734:32: error: to be safe all intermediate pointers in
cast from 'char **' to 'const char **' must be 'const' qualified
[-Werror=cast-qual]
```
There may be a better solution, but I couldn't find it.
These cases are handled in separate subcommits, but without further
markup.
If you see a `-Wcast-qual` warning in curl, we appreciate your report
about it.
Closes#16142
`./configure` mingw32ce builds enable C99 mode automatically, that
triggers compiler warnings in gcc 4.4.0. We initially worked it around
in CI by suppressing the detection of C99 with `ac_cv_prog_cc_c99=no`.
Replace it with automatically silencing the bogus warnings in C99 mode,
for all build systems:
```
lib/ftp.c: In function 'Curl_GetFTPResponse':
lib/ftp.c:726: error: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
lib/ws.c: In function 'ws_dec_pass_payload':
lib/ws.c:304: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/ws.c: In function 'ws_enc_write_head':
lib/ws.c:581: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'long int'
lib/vtls/schannel.c: In function 'schannel_connect_step1':
lib/vtls/schannel.c:1122: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_connect_step2':
lib/vtls/schannel.c:1311: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_send':
lib/vtls/schannel.c:1793: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c:1810: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_shutdown':
lib/vtls/schannel.c:2286: error: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
lib/vtls/vtls.c: In function 'ssl_cf_recv':
lib/vtls/vtls.c:1422: error: format '%zd' expects type 'signed size_t', but argument 5 has type 'ssize_t'
```
Ref: https://github.com/curl/curl/actions/runs/13533841306/job/37821720902?pr=16492#step:9:20
Also: simplify Windows CE job configuration in GHA/windows.
Follow-up to 2a292c3984#15975Closes#16492
Make it possible to build curl for Windows CE using the CeGCC toolchain.
With both CMake and autotools, including tests and examples, also in CI.
The build configuration is the default one with Schannel enabled. No
3rd-party dependencies have been tested.
Also revive old code to make Schannel build with Windows CE, including
certificate verification.
Builds have been throughougly tested. But, I've made no functional tests
for this PR. Some parts (esp. file operations, like truncate and seek)
are stubbed out and likely broken as a result. Test servers build, but
they do not work on Windows CE. This patch substitutes `fstat()` calls
with `stat()`, which operate on filenames, not file handles. This may or
may not work and/or may not be secure.
About CeGCC: I used the latest available macOS binary build v0.59.1
r1397 from 2009, in native `mingw32ce` build mode. CeGCC is in effect
MinGW + GCC 4.4.0 + old/classic-mingw Windows headers. It targets
Windows CE v3.0 according to its `_WIN32_WCE` value. It means this PR
restores portions of old/classic-mingw support. It makes the Windows CE
codepath compatible with GCC 4.4.0. It also adds workaround for CMake,
which cannot identify and configure this toolchain out of the box.
Notes:
- CMake doesn't recognize CeGCC/mingw32ce, necessitating tricks as seen
with Amiga and MS-DOS.
- CMake doesn't set `MINGW` for mingw32ce. Set it and `MINGW32CE`
manually as a helper variable, in addition to `WINCE` which CMake sets
based on `CMAKE_SYSTEM_NAME`.
- CMake fails to create an implib for `libcurl.dll`, due to not
recognizing the platform as a Windowsy one. This patch adds the
necessary workaround to make it work.
- headers shipping with CeGCC miss some things curl needs for Schannel
support. Fixed by restoring and renovating code previously deleted
old-mingw code.
- it's sometime non-trivial to figure out if a fallout is WinCE,
mingw32ce, old-mingw, or GCC version-specific.
- WinCE is always Unicode. With exceptions: no `wmain`,
`GetProcAddress()`.
- `_fileno()` is said to convert from `FILE *` to `void *` which is
a Win32 file `HANDLE`. (This patch doesn't use this, but with further
effort it probably could be.)
https://stackoverflow.com/questions/3989545/how-do-i-get-the-file-handle-from-the-fopen-file-structure
- WinCE has no signals, current directory, stdio/CRT file handles, no
`_get_osfhandle()`, no `errno`, no `errno.h`. Some of this stuff is
standard C89, yet missing from this platform. Microsoft expects
Windows CE apps to use Win32 file API and `FILE *` exclusively.
- revived CeGCC here (not tested for this PR):
https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/
On `UNDER_CE` vs. `_WIN32_WCE`: (This patch settled on `UNDER_CE`)
- A custom VS2008 WinCE toolchain does not set any of these.
The compiler binaries don't contain these strings, and has no compiler
option for targeting WinCE, hinting that a vanilla toolchain isn't
setting any of them either.
- `UNDER_CE` is automatically defined by the CeGCC compiler.
https://cegcc.sourceforge.net/docs/details.html
- `UNDER_CE` is similar to `_WIN32`, except it's not set automatically
by all compilers. It's not supposed to have any value, like a version.
(Though e.g. OpenSSL sets it to a version)
- `_WIN32_WCE` is the CE counterpart of the non-CE `_WIN32_WINNT` macro.
That does return the targeted Windows CE version.
- `_WIN32_WCE` is not defined by compilers, and relies on a header
setting it to a default, or the build to set it to the desired target
version. This is also how `_WIN32_WINNT` works.
- `_WIN32_WCE` default is set by `windef.h` in CeGCC.
- `_WIN32_WCE` isn't set to a default by MSVC Windows CE headers (the
ones I checked at least).
- CMake sets `_WIN32_WCE=<ver>`, `UNDER_CE`, `WINCE` for MSVC WinCE.
- `_WIN32_WCE` seems more popular in other projects, including CeGCC
itself. `zlib` is a notable exception amongst curl dependencies,
which uses `UNDER_CE`.
- Since `_WIN32_WCE` needs "certain" headers to have it defined, it's
undefined depending on headers included beforehand.
- `curl/curl.h` re-uses `_WIN32_WCE`'s as a self-guard, relying on
its not-(necessarily)-defined-by-default property:
25b445e479/include/curl/curl.h (L77)
Toolchain downloads:
- Windows:
https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_cygwin1.7_r1399.tar.bz2
- macOS Intel:
https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_snowleopard_r1397.tar.bz2Closes#15975
Before this patch curl code was redefining `getaddrinfo` and
`freeaddrinfo` system symbols to plug in its debug wrappers. This was
causing pains to avoid applying the redefinitions to system headers
defining these functions, and to the local debug wrappers. Especially
in unity builds. It also required workarounds for systems where these
symbols are already macros.
Introduce curl-namespaced macros for these functions and use them.
This allows to drop all workarounds and makes it work in all envs,
local targets and unity/bundle combinations.
Also drop GHA/windows workaround and use the same unity batch across
all jobs. Follow-up to 29e4eda631#16272
Ref: #16272
Ref: 71cf0d1fca#14772
Ref: 3efba94f77#14765
Ref: f7d5f47059#14399Closes#16274
LibreSSL headers emit this warning because we included `wincrypt.h`
before them. We have to include `wincrypt.h` before OpenSSL headers
to avoid symbol collisions when using other forks. LibreSSL 3.8.2+
offers a macro to silence its warnings to avoid this issue. This patch
sets it.
This allows to stop setting this macro in curl-for-win builds.
Warnings seen with MinGW with cmake non-unity (also unity batch=30):
```
[156/219] Building C object lib/CMakeFiles/libcurl_object.dir/vtls/openssl.c.obj
In file included from lib/vtls/openssl.h:35,
from lib/vtls/openssl.c:53:
dep/libressl-win-x64/include/openssl/ossl_typ.h:90:2: warning: #warning overriding WinCrypt defines [-Wcpp]
90 | #warning overriding WinCrypt defines
| ^~~~~~~
In file included from dep/libressl-win-x64/include/openssl/pem.h:71,
from dep/libressl-win-x64/include/openssl/ssl.h:151,
from lib/vtls/openssl.h:36:
dep/libressl-win-x64/include/openssl/x509.h:108:2: warning: #warning overriding WinCrypt defines [-Wcpp]
108 | #warning overriding WinCrypt defines
| ^~~~~~~
In file included from dep/libressl-win-x64/include/openssl/x509.h:319:
dep/libressl-win-x64/include/openssl/pkcs7.h:77:2: warning: #warning overriding WinCrypt defines [-Wcpp]
77 | #warning overriding WinCrypt defines
| ^~~~~~~
```
Ref: https://github.com/libressl/portable/issues/910
Ref: https://github.com/libressl/portable/pull/924
Ref: e7fe6caab2
Ref: 760ccfcc91Closes#16273
We don't pursue this, and the necessary `#pragma` got in the way of
compiling curl with gcc 4.2 and older. Drop the logic completely.
Follow-up to 8a266ac488#15939
Reported-by: prpr19xx on Github
Fixes#16152Closes#16157
- replace deprecated `ares_init()` call with `ares_init_options()`.
Follow-up to 0d4fdbf15d#16054
- dedupe `CARES_STATICLIB` initalizations into `curl_setup.h`, to
ensure it's defined before the first (and every) `ares.h` include and
avoid a potential confusion.
- move `CARES_NO_DEPRECATED` from build level to `curl_setup.h`.
To work regardless of build system.
It is necessary because curl calls `ares_getsock()` from two places,
of which one feeds a chain of wrappers: `Curl_ares_getsock()`,
`Curl_resolver_getsock()`, `Curl_resolv_getsock()`.
Closes#16131
Allow building with c-ares and yet use threaded resolver for the main
host A/AAAA resolving:
`--with-ares` provides the c-ares install path and defaults to use
c-ares for name resolving
`--with-threaded-resolver` still uses c-ares in the build (for HTTPS)
but uses the threaded resolver for "normal" resolves.
It works similarly for cmake: ENABLE_ARES enables ares, and if
ENABLE_THREADED_RESOLVER also is set, c-ares is used for HTTPS RR and
the threaded resolver for "normal" resolves.
HTTPSRR and c-ares-rr are new features return by curl_version_info() and
thus shown by curl -V.
The c-ares-rr feature bit is there to make it possible to distinguish
between builds using c-ares for all name resolves and builds that use
the threaded resolves for the regular name resolves and c-ares for
HTTPSRR only. "c-ares-rr" means it does not use c-ares for "plain" name
resolves.
HTTPSRR support is EXPERIMENTAL only.
Closes#16054
They were more or less the same, but each missed some things the other
had. Windows CE is a subset of Win32, make the headers reflect that and
avoid duplications.
Ref: #15975Closes#16038
