- update `actions/cache` from 5.0.3 to 5.0.4
- update `actions/download-artifact` from 7.0.0 to 8.0.1
- update `actions/upload-artifact` from 6.0.0 to 7.0.0
- update `msys2/setup-msys2` from 2.30.0 to 2.31.0
- update pip `ruff` from 0.15.7 to 0.15.8
Closes#21195Closes#21197
- fail if all retries failed.
- run `dpkg --configure -a` after an aborted slow attempt.
```
Selecting previously unselected package libsys-hostname-long-perl.
Error: slow server, retry
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
[...]
```
Bug: https://github.com/curl/curl/pull/21107#issuecomment-4163506100
Follow-up to 5172ba5475#21107Closes#21181
It's been going on for almost a year, chances seem slim to have this
fixed upstream.
The observed issue is that on GitHub-supplied CI runner images,
sometimes, `apt-get install` using the stock distro server
`http://azure.archive.ubuntu.com/ubuntu` sees extreme slowness while
downloading data, then reaching the job timeout and aborting, making CI
red and necessitating a manual restart of the failed job(s).
In majority of cases the install step takes no longer than 8-40 seconds
(download + install), while in the failing case it takes 10-20+ minutes
just to download.
Earlier I slimmed down installs to avoid unnecessary packages, which
mitigated, but did not completely fix the issue.
Example:
https://github.com/curl/curl/actions/runs/23599596928/job/68725576899?pr=21105
Follow-up to 0455d8772a#18509Closes#21107
Verify if lines are not longer than 192 characters. Also verify if lines
have less than 79 repeat spaces (and fix one fallout).
To improve readability by avoiding long lines and to prevent adding
overly long lines with text that may go unnoticed in an editor or diff
viewer.
In addition to pre-existing line length limits: 79 for C, 132 for CMake
sources.
Also:
- spacecheck: fix/harden allowlist regexes.
- spacecheck: tidy-up quotes and simplify escaping.
- spacecheck: allow folding strings with repeat spaces.
- GHA: fix a suppressed shellcheck warning.
- GHA/macos: simplify by dropping brew bundle.
- test1119.pl: precompile a regex.
- FAQ.md: delete very long link to a Windows 7/2008 support article
that's lost it relevance.
Closes#21087
- librtmp has no test cases, makes no proper releases and has not had a
single commit within the last year
- librtmp parses the URL itself and requires non-compliant URLs for this
- we have no RTMP tests
- RTMP was used by 2.2% of curl users (self-identified in the 2025
survey)
Closes#20673
- update action `actions/cache` from 5.0.1 to 5.0.3
- update action `github/codeql-action` from 4.31.9 to 4.32.4
- update pip `filelock` from 3.20.3 to 3.24.3
- update pip `ruff` from 0.14.14 to 0.15.2
Closes#20782Closes#20783
`scan-build` is a (Perl) wrapper around clang's built-in `--analyze`
option. Which look similar or identical to clang-tidy checkers under
the `clang-analyzer-*` namespace:
https://clang.llvm.org/docs/ClangStaticAnalyzer.html
Unless somebody has other information, it appears redundant to run
scan-build in parallel with clang-tidy in CI, now that the latter is
working reliably and with good performance for all curl components.
Another scan-build issue is the lack of a markup to suppress false
positives. It ignores `NOLINT`, yet finds the same false positives as
clang-tidy. This happens with scan-build v20+. v18 is silent, but it's
a blocker to upgrade to a newer version.
scan-build may still be a useful when combined with autotools, where
clang-tidy support is incomplete, slow (no parallelism), and uses
a distinct make target, which does not build binaries in the same pass.
But, scan-build also lacks extra checkers that are now enabled for
clang-tidy.
The clang-tidy job is also 30-40s faster than the one it replaced.
Also:
- drop scan-build job configured the same way as a clang-tidy one.
CI time saved: 6m30s
- bump to clang-20 (from 18) in the replacement job.
- build tests in the replacement job.
To verify a cmake command-line reconstruction issue only hit in this
job in CI.
CI time cost: 1m40s
- replacement job caught a minor, new, issue.
Ref: b2076d3c2f#20752
- drop unused scan-build logic.
Bug: https://github.com/curl/curl/pull/20732#issuecomment-3963873838
Ref: https://github.com/curl/curl/pull/20732#issuecomment-3967479228Closes#20751
Checking lib and src under 3m15s versus 7m15s.
Downside: autotools clang-tidy support is no longer CI-tested.
The reason for the slowness is invoking a single clang-tidy command with
all source files, and clang-tidy checking them in a single thread,
sequentially. clang-tidy offers a `run-clang-tidy` Python script for
parallel processing, which may help with this. However at this point
it's more practical to use cmake, which also supports verifying the
whole codebase, not only lib and src.
Also:
- bump clang-tidy to the latest available, v20 (from v18).
- enable running clang-tidy on tests. Takes under 2 minutes.
Also tried `_CURL_TESTS_CONCAT=ON`, it brings down the build tests step
from 1m47s to 54s, saving 1 minute. Skipped using it for now.
Closes#20725
Fix bigger and smaller kinks in how clang-tidy is configured and used.
Sync behavior more between autotools and cmake, lib/src and tests. Bump
clang-tidy minimum version and prepare logic to allow using clang-tidy
to a fuller extent.
- move clang-tidy settings from builds to a new `.clang-tidy.yml`.
To make it easy to see and edit checks at one place. Also to allow
using the `--checks=` option internally to silence tests-specific
checks. (clang-tidy does not support multiple `--check=` options via
the command-line.)
Use explicit `--config-file=` option to point to the configuration.
- .clang-tidy.yml: link to documentation.
- suppress `clang-diagnostic-nullability-extension` due to a false
positive in libtests with `CURL_WERROR=ON` and `PICKY_COMPILER=OFF`.
- .clang-tidy.yml: enable `portability-*`, `misc-const-correctness`.
- drop `--quiet` clang-tidy option by default to make its working a bit
more transparent. The extra output is minimial.
- consistently use double-dashes in clang-tidy command-line options.
Supported by clang-tidy 9.0.0+ (2019-09-19). Before this patch single
and double were used arbitrarily.
- src/tool_parsecfg: silence false positive `clang-analyzer-unix.Stream`.
Seen with clang 18 + clang-tidy 19 and 20 (only with autotools.)
- INTERNALS: require clang-tidy 14.0.0+. For the `--config-file` option.
- INTERNALS: recommend clang-tidy 19.1.0+, to avoid bogus
`clang-analyzer-valist.Uninitialized` warnings. (bug details below)
autotools:
- allow configuring the clang-tidy tool via `CLANG_TIDY` env.
Also to use in GHA to point to a suffixed clang-tody tool.
- fix to pass CFLAGS to lib, src sources.
(keep omitting them when using a non-clang compiler.)
- fix to pass `--warnings-as-errors=*` in quotes to avoid globbing.
cmake:
- fix to not pass an empty `-I` to clang-tidy.
- fix to pass CFLAGS (picky warnings) to clang-tidy for test sources.
(keep omitting them when using a non-clang compiler.)
- fix to disable `clang-diagnostic-unused-function` for test sources.
(tests have static entry points, which trigger this check when
checking them as individidual sources.)
- fix forwarding `CURL_CLANG_TIDYFLAGS` to clang-tidy.
- force disable picky warnings when running clang-tidy with a non-clang
compiler. To not pass these flags when checking lib and src.
CI:
- GHA/linux: avoid clang-tidy bug by upgrading to v19, and drop the
workaround.
- GHA/linux: switch to clang from gcc in the clang-tidy job. Using gcc
doesn't allow passing CFLAGS to clang-tidy, making it less effective.
(My guess this was one factor contributing to this job often missing
to find certain issues compared to GHA/macos.)
I recomment using clang-tidy with a clang compiler, preferably the same
version or one that's compatible. Other cases are best effort, and may
fail if a C flag is passed to clang-tidy that it does not understand.
Picky warnings are mostly omitted when using a non-clang compiler,
reducing its usefulness.
Details and reproducer for the v18 (and earlier) clang-tidy bug,
previously affecting the GHA/linux job:
clang-tidy <=18 emits false warnings way when passing multiple C sources
at once (as done with autotools):
```sh
cat > src1.c <<EOF
#include <string.h>
static void dummy(void *p) { memcmp(p, p, 0); }
EOF
cat > src2.c <<EOF
#include <stdarg.h>
void vafunc(int option, ...)
{
va_list param;
va_start(param, option);
if(option)
(void)va_arg(param, int);
va_end(param);
}
EOF
/opt/homebrew/opt/llvm@18/bin/clang-tidy --checks=clang-analyzer-valist.Uninitialized src1.c src2.c
# src2.c:7:11: warning: va_arg() is called on an uninitialized va_list [clang-analyzer-valist.Uninitialized]
```
Follow-up to e86542038d#17047Closes#20605
- update `actions/checkout` from 6.0.1 to 6.0.2
- update `ruff` from 0.14.11 to 0.14.14
- update `cryptography` from 46.0.3 to 46.0.4
- update `psutil` from 7.2.1 to 7.2.2
- update `websockets` from 15.0.1 to 16.0
Closes#20490Closes#20491
To avoid unnecessarily installing Intel C for any `<pkg>-intel` locally
built dependency.
Follow-up to ab8ccaed24#20392
Follow-up to d9fe60d457#20248Closes#20400
To enable known linker options dropping unused, dead, code and data from
the executables built.
Useful to reduce binary sizes for curl, libcurl shared lib and apps
linking static libcurl. It's effective on both "unity" and non-unity
builds. Aligning "unity" build sizes with default, non-unity ones.
Supported platforms: Apple, MSVC, llvm/clang and GCC on all tested
platforms: Linux, BSDs, Windows, MSYS2/Cygwin, Android, MS-DOS.
Notes:
- Static libraries grow 20-30% with non-Apple toolchains.
This effect is controlled by separate, optional compiler flags on
non-Apple. This patch enables them automatically for public binaries
(libcurl and curl tool), and leaves them off for internal/test ones.
- MSVC enables this option by default for 'Release' configurations.
The curl build option has no effect on it.
- Observed effect on VS2010 is negligible. VS2012+ is recommended.
- Works with LTO, Fil-C.
- No observed/conclusive effect on build speed.
- On Windows with clang/gcc (mingw-w64/MSYS2/Cygwin) it also enables
`-fno-asynchronous-unwind-tables` as a workaround to make
the toolchain options actually work.
Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=11539
Thanks-to: Andarwinux
Also:
- GHA: enable in Linux and MinGW jobs to test it. Size changes:
- linux aws-lc H3:
curl: 2000000 -> 1937152, libcurl.a: 2065724 -> 2716532 bytes
- macos clang HTTP-only:
curl: 1364376 -> 128799 bytes, libcurl.a: unchanged
- macos llvm MultiSSL:
curl: 410056 -> 405720, libcurl.dylib: 1350336 -> 1348480 bytes
- mingw schannel c-ares U:
curl: 1588736 -> 1507328, libcurl-d.a: 3322040 -> 3884746 bytes
bld: 34 -> 35MB
- GHA: enable in MSVC and Apple jobs to reduce disk footprint, with no
obvious downside. Size changes:
- AppVeyor CI VS2019:
curl: 2339840 -> 1295872, libcurl-d.dll: 3155968 -> 1900544 bytes
bld: 161 -> 97MB
- AppVeyor CI VS2022 clang-cl:
curl: 2933248 -> 2332160, libcurl-d.lib: 4762688 -> 5511330 bytes
bld: 133 -> 121MB
- AppVeyor CI VS2022 HTTP-only:
curl: 3514368 -> 2177024, libcurl-d.lib: 2538420 -> 3151740 bytes
bld: 137 -> 83MB
- GHA intel:
curl: 2629120 -> 2023424, libcurl-d.lib: 4366652 -> 5350670 bytes
bld: 86 -> 69MB
- GHA arm64:
curl: 2832896 -> 2063872, libcurl-d.lib: 4690616 -> 5597250 bytes
bld: 82 -> 66MB
Refs:
https://maskray.me/blog/2021-02-28-linker-garbage-collectionhttps://web.archive.org/web/20110811230637/msdn.microsoft.com/en-us/library/bxwfs976.aspx (VS2010)
https://learn.microsoft.com/cpp/build/reference/opt-optimizationshttps://learn.microsoft.com/cpp/build/reference/gy-enable-function-level-linkingCloses#20357
When the compiler supports C99.
- map logging functions to macro stubs when verbose logging is disabled
and the compiler is C99. Make sure these stubs silence unused variable
warnings for non-variadic arguments.
Before this patch they mapped to function stubs, the same codepath
used for C89 compiler in this configuration.
- introduce new macros to tell the compiler which code to include
when verbose code is active, or inactive:
- `CURLVERBOSE`: defined when verbose code is active.
To enclose blocks of code only used for verbose logging.
- `VERBOSE(statement);`:
compile statement when verbose code is active.
To mark code lines only used for verbose logging.
- `NOVERBOSE(statement);`:
compile statement when verbose code is inactive.
To suppress warnings for arguments passed to logging functions via
printf masks, e.g. `NOVERBOSE((void)ipaddress);`, yet keeping
the warning in verbose builds.
Note these macros are not the same as `CURL_DISABLE_VERBOSE_STRINGS`.
Verbose code is always active in C89 mode (without variadic macro
support).
- drop existing uses of `CURL_DISABLE_VERBOSE_STRINGS` where redundant,
or replace with the above macros. Ending up reducing the number of
`#ifdef`s, and also the number of lines.
Assisted-by: Daniel Stenberg
Assisted-by: Jay Satiro
Reported-by: Dan Fandrich
Fixes#20341
Refs: #12105#12167Closes#20353
- `stdbool.h` is also included via system headers. Disabling it from curl
does not fix it. Silencing lots of these:
```
curl/lib/curlx/warnless.h:64:1: warning: '_Bool' is a C99 extension [-Wc99-extensions]
64 | bool curlx_sztouz(ssize_t sznum, size_t *puznum);
| ^
/Library/Developer/CommandLineTools/usr/lib/clang/17/include/stdbool.h:24:14: note: expanded from macro 'bool'
24 | #define bool _Bool
| ^
```
- silence `-Wcomma` warnings.
in favor of the global silencing approach, since a couple of more of
these were hit (in vquic, tool1622, unit1309, unit1636), and it seems
silly to update them all.
Revert e8189c4420#20362
Also:
- cmake: include C standard in 'platform flags' log line.
- GHA/macos: switch a job to C89 to verify.
- GHA/linux: show 'C89' in job names.
Ref: https://cmake.org/cmake/help/v3.7/variable/CMAKE_C_STANDARD.htmlCloses#20363
Drop separate `TrackMemory` (aka `CURLDEBUG`) debug feature.
After recent changes (thread-safety,
193cb00ce9, and updates leading up to
it), `TrackMemory` is unlikely to cause build or runtime issues.
To simplify builds and debug options, enable `TrackMemory`
unconditionally for debug-enabled (aka `DEBUGBUILD`) builds. Before
this patch, this was already the default, with an option to disable
it, or enable it in non-debug-enabled builds.
Note, in practice these two debug options already went hand in hand. It
was not possible to toggle them separately for a long time due to bugs,
before 59dc9f7e69 (2024-05-28) fixed it.
This patch also removes/deprecates separate knobs and feature flags for
`TrackMemory`:
- autotools: `--enable-curldebug`/`--disable-curldebug`
- cmake: `-DENABLE_CURLDEBUG=ON`/`OFF`
- C macro: `CURLDEBUG`
- libcurl: `CURL_VERSION_CURLDEBUG` symbol deprecated in favor
of `CURL_VERSION_DEBUG`. They always return the same value after this
patch.
Also:
- drop `TrackMemory` from `curl -V` output.
- rename internal `CURLDEBUG` macro to `CURL_MEMDEBUG` internally.
To avoid confusion with `DEBUGBUILD`, but to keep guarding
`TrackMemory`-related internals for readability.
- runtests: bind `TrackMemory` to debug feature. Keep it a separate
test feature requirement, for clarity.
- CI: drop test builds for combinations of the two options.
- GHA/linux: no longer disable TrackMemory in the TSAN job.
Ref: https://github.com/curl/curl/pull/20328#issuecomment-3754528407Closes#20331
To simplify the directory layout.
- OS400 and vms support move from `packages` to `projects`.
- Windows README and `generate.bat` files move from `projects`
to `projects/Windows`.
Closes#20271
Turns out in practice the internal cache name contains the arch where it
matters (arm or dual-arch local builds), which is part of the cache key
string. Drop `runner.arch` to avoid two arch strings in the key.
Cache keys without an explicit arch designator mean intel.
Revert ff78af5752#20234Closes#20249
`mbedtls-arm` and `mbedtls-prev` were matching `contains()` expressions
looking for `mbedtls`. It caused an unnecessary cache restore and an
redundant mbedtls build on bumps, and made the build flavors require
different local directory names to avoid this accidental collision.
Also drop `-threadsafe` from internal names. All local builds are.
Follow-up to 8806035344#20240
Follow-up to 3a305831d1#19077Closes#20248
All libresll jobs, wolfssl-all, and one mbedtls job.
As noted earlier, arm jobs run faster than intel ones, especially
valgrind steps that run almost twice as fast. Package install runs
slower, but this is offset by faster build and test steps, even in
non-valgrind jobs.
Follow-up to ff78af5752#20234
Follow-up to 2b0d8dcc16#20231Closes#20246
