curl-curl/docs/INTERNALS.md
Viktor Szakats 4497dbd9ac
clang-tidy: fixes and improvements
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 #17047

Closes #20605
2026-02-19 00:02:11 +01:00

2.4 KiB

curl internals

The canonical libcurl internals documentation is now in the everything curl book. This file lists supported versions of libs and build tools.

Portability

We write curl and libcurl to compile with C89 compilers on 32-bit and up machines. Most of libcurl assumes more or less POSIX compliance but that is not a requirement. The compiler must support a 64-bit integer type as well as supply a stdint.h header file that defines C99-style fixed-width integer types like uint32_t.

We write libcurl to build and work with lots of third party tools, and we want it to remain functional and buildable with these and later versions (older versions may still work but is not what we work hard to maintain):

Dependencies

We aim to support these or later versions.

  • brotli 1.0.0 (2017-09-21)
  • c-ares 1.6.0 (2008-12-09)
  • GnuTLS 3.6.5 (2018-12-01)
  • libidn2 2.0.0 (2017-03-29)
  • LibreSSL 2.9.1 (2019-04-22)
  • libssh 0.9.0 (2019-06-28)
  • libssh2 1.9.0 (2019-06-20)
  • mbedTLS 3.2.0 (2022-07-11)
  • MIT Kerberos 1.3 (2003-07-31)
  • nghttp2 1.15.0 (2016-09-25)
  • OpenLDAP 2.0 (2000-08-01)
  • OpenSSL 3.0.0 (2021-09-07)
  • Windows Vista 6.0 (2006-11-08 - 2012-04-10)
  • wolfSSL 3.4.6 (2017-09-22)
  • zlib 1.2.5.2 (2011-12-11)
  • zstd 1.0 (2016-08-31)

Build tools

When writing code (mostly for generating stuff included in release tarballs) we use a few "build tools" and we make sure that we remain functional with these versions:

  • clang-tidy 14.0.0 (2022-03-23), recommended: 19.1.0 or later (2024-09-17)
  • cmake 3.7 (2016-11-11)
  • GNU autoconf 2.59 (2003-11-06)
  • GNU automake 1.7 (2002-09-25)
  • GNU libtool 1.4.2 (2001-09-11)
  • GNU m4 1.4 (2007-09-21)
  • mingw-w64 3.0 (2013-09-20)
  • perl 5.8 (2002-07-19), on Windows: 5.22 (2015-06-01)
  • Visual Studio 2010 10.0 (2010-04-12 - 2020-07-14)

Library Symbols

All symbols used internally in libcurl must use a Curl_ prefix if they are used in more than a single file. Single-file symbols must be made static. Public ("exported") symbols must use a curl_ prefix. Public API functions are marked with CURL_EXTERN in the public header files so that all others can be hidden on platforms where this is possible.