Apparently regexps do not work as expected.
Also seems to pick up some implicit rule from the local machine,
but found no option to make the hidden magic visible.
- autotools: fix auto-detection on the Windows platform.
It was mis-detected when targeting Windows XP/2003 64-bit.
It was permanently undetected when building for Windows 32-bit.
```
lib/url.c: In function 'zonefrom_url':
lib/url.c:1802:18: error: implicit declaration of function 'if_nametoindex' [-Wimplicit-function-declaration]
1802 | scopeidx = if_nametoindex(zoneid);
| ^~~~~~~~~~~~~~
lib/url.c:1802:18: error: nested extern declaration of 'if_nametoindex' [-Werror=nested-externs]
```
Ref: https://github.com/curl/curl/actions/runs/16405598782/job/46351023138?pr=17982#step:10:29
Reported-by: LoRd_MuldeR
Fixes#17979
Without this patch the workaround for the 8.15.0 release is:
`export ac_cv_func_if_nametoindex=0` for Windows XP/2003 64-bit.
Background: Checking for the `if_nametoindex()` function via
`AC_CHECK_FUNCS()` (autotools) or `check_function_exists()` (cmake) do
not work on Windows, for two reasons:
- the function may be disabled at compile-time in Windows headers
when targeting old Windows versions (XP or WS2003 in curl context)
via `_WIN32_WINNT`. But it's always present in the system implib
`iphlpapi` where these checks are looking.
- for 32-bit Windows the function signature in the implib requires
a 4-byte argument, while these checks always use no arguments,
making them always fail.
- cmake: call `if_nametoindex` dynamically with mingw-w64 v1.0.
This mingw-w64 version lacks prototype and implib entry for it.
- cmake: add auto-detection for Windows and use as a fallback for
non-pre-fill cases.
- cmake: disable pre-fill with `_CURL_PREFILL=OFF`. (for testing)
- cmake: disable pre-fill for untested compilers. (i.e. non-MSVC,
non-mingw64)
- GHA/windows: make an autotools job build for Windows XP.
Follow-up to 0d71b18153#17413Closes#17982
To fix test 1308 in MultiSSL builds.
Failure was caused by the random number generator virtual function being
NULL, instead of pointing to the implementation in the runtime-selected
TLS backend. This could happen in MultiSSL builds when a functionality
was asking for a random number without triggering a VTLS function table
initialization first. Such functionality is MIME, or form data via MIME.
The reason CI did not catch it in an earlier MultiSSL GHA/windows job,
is that it was a debug-enabled one. In debug-enabled builds the test
runner was overriding the random number generator for all tests.
Fixed this by moving the override to the tests requiring it, via
1fcf22585f#17971, enabling debug builds
to catch this issue.
Enable MultiSSL in two CI jobs, to verify this patch.
Fixing:
```
test 1308...[formpost tests]
libtests returned 44, when expecting 0
1308: exit FAILED
[...]
=== Start of file stderr1308
URL: log/3/test-1308
tests/libtest/lib1308.c:70 Assertion 'res == 0' FAILED: curl_formget returned error
tests/libtest/lib1308.c:72 Assertion 'total_size == 518' FAILED: curl_formget got wrong size back
tests/libtest/lib1308.c:88 Assertion 'res == 0' FAILED: curl_formget returned error
tests/libtest/lib1308.c:89 Assertion 'total_size == 899' FAILED: curl_formget got wrong size back
```
Ref: https://github.com/curl/curl/actions/runs/16387693424/job/46309536359?pr=17963#step:16:2515
Bug: https://github.com/curl/curl/pull/17963#issuecomment-3092282057Closes#17970
