Simplify automatic support of Unix-like platforms across modules

[gilles-peskine-arm]

There are several places in TF-PSA-Crypto and Mbed TLS that have an adherence on non-standard C features, either mandatory or optional. We have built-in support for Unix-like platforms and for Windows, and sometimes ways to configure the library on other platforms. “Unix-like” covers a vast range of systems, including:

• Linux kernel with several possible libc.
• Unix implementations from a single vendor such as *BSD, macOS, QNX, AIX, …
• Various Unix/POSIX/Linux layers on Windows.
• Various embedded systems with partial Unix APIs.

The goal of this issue is to simplify the code that we use to detect, and adapt to, Unix-like platforms, so that we are less afraid of breaking things if we need to fix a bug in the next long-time support branch. It covers both TF-PSA-Crypto and Mbed TLS.

Here are some known problems, as of TF-PSA-Crypto 1.0.0 and Mbed TLS 4.0.0:

• We include unistd.h and other Unix headers in many different places: platform_util.c, threading.c, unistd.c, net_sockets.c (and that's just for the library, the rest matters less). Each file has a different idea of whether to include QNX, Haiku, Midipix…
• Compiler options can break the build as they may influence which symbols are declared in system headers.
• We have hacks to allow a non-C99 printf in debug.h, only for Windows. These hacks may or may not work correctly because the printf variant (standard C99 or Windows legacy) is determined when debug.c is built, but the format strings is determined when ssl_*.c is built. They may end up being different if, for example, a module using debug also defines a macro such as _POSIX_C_SOURCE or _XOPEN_SOURCE — then Mingw will pull in the GNU printf implementation which is C99-compliant, instead of the default one which isn't. The way Mingw picks the printf implementation seems to have been overhauled in version 13, released in June 2025, and our code may not work with that version (I suspect that's the cause of MinGW-w64 GCC build fails with -Werror=format: MBEDTLS_PRINTF_LONGLONG mismatches long long in ssl_client.c/ssl_tls12_server.c mbedtls#10566). We've had other problems with these hacks before (Wrong MSVC version guard for C99 format size specifiers mbedtls#10017).

Out of scope:

• Providing additional configurability is out of scope here. It is of course desirable, but it would take a lot of effort. This issue focusing on what works out of the box.
• Only the libraries is in scope. While it would be nice for the sample programs to run on more platforms, it's a lot less important. Test tools are completely out of scope, we only care about them running on our CI environment and on developer machines.

[gilles-peskine-arm]

printf on Windows

In mbedtls/debug.h, we have some definitions of printf format specifiers (MBEDTLS_PRINTF_SIZET and MBEDTLS_PRINTF_LONGLONG) to cater for non-C99-compliant printf on older toolchains for Windows (MingW and MSVC).

printf with MSVC

With MSVC, the alternative definitions are only present, and only needed, for MSVC before 19.0 (_MSC_VER < 1900), which corresponds to Visual Studio before 2015 — VS 2015 supports %lld and %zu. Even Mbed TLS 3.6 requires at least VS 2017, and we've removed versions older than that on our CI. So even in Mbed TLS 3.6, for MSVC, we could use the standard format specifiers.

printf with MingW

(Note: here MingW refers to Mingw-w64. I assume the original MingW is dead.)

With MingW, I have been experimenting with several versions. I tried Ubuntu LTS releases, and I'm using Wine for testing so things may be different with a real Windows. I did my testing on v3.6.5-73-g366e469, which doesn't differ from development in the relevant part. I used CFLAGS="-O1 -Wall -Wextra -Werror" and I tried both CC=x86_64-w64-mingw32-gcc(build for 64-bit Windows) andCC=i686-w64-mingw32-gcc(build for 32-bit Windows). I built the library and rantest_suite_debug` with a few extra test cases to gain more confidence.

• [16.04] MingW 4.0.4: the compilation fails with

  library/entropy_poll.c:43:21: fatal error: intsafe.h: No such file or directory
  

  I conclude that MingW 4 is already not supported for Mbed TLS 3.6 LTS.
• [18.04] MingW 5.0.3: the compilation fails with -Wformat warnings about both %zu and %llu. If I bypass the warnings with -Werror, the long long tests pass but the size_t tests fail.
• [20.04] MingW 7.0.0: the compilation fails with -Wformat warnings about both %zu and %llu. If I bypass the warnings with -Werror, the tests pass.
• [22.04] MingW 8.0.0: the build succeeds without warnings and the tests pass.
• [24.04] MingW 11.010: the build succeeds without warnings and the tests pass.

Note that this is with the default printf selection. MingW can be told to select a more standards-compliant implementation of printf and other stdio functions by defining the macro __USE_MINGW_ANSI_STDIO.

Conclusion: we only need the special case for older versions of MingW, and only for size_t. I believe that the first version where the standard size_t specifier works out of the box is MingW 6.0.0, thanks to this commit, first released in 6.0.0 (but insufficient to get a build without warnings).

On our CI, we currently do MingW builds with:

• MingW 5.0.3 (with GCC 7.3-win32) on Ubuntu 18.04 (where we don't run tests).
• MingW ??? (GCC 8.3.0) on win32
• MingW ??? (GCC ???) on Windows

Prior history:

• From before 3.0: Fixes for invalid printf format specifiers mbedtls#3579, Use proper formatting macros when using MinGW provided stdio mbedtls#4497
• After 3.6.0, but before removing VS 2013 from our CI: [Backport 3.6] Fix preprocessor guards for C99 format size specifiers mbedtls#10043
• Pending: [3.6] Fix format specifiers for MinGW ANSI stdio mbedtls#10165
• Reported recently: MinGW-w64 GCC build fails with -Werror=format: MBEDTLS_PRINTF_LONGLONG mismatches long long in ssl_client.c/ssl_tls12_server.c mbedtls#10566

Going by our minimal support requirements, we could have required a C99-compliant printf (and thus forced __USE_MINGW_ANSI_STDIO on for older MingW, or just dropped support for older MingW) as soon as Mbed TLS 3.6.0, when we dropped support for Visual Studio 2013. However, we didn't do it then, so I it's too late to break older MingW on the 3.6 LTS. We may consider enabling __USE_MINGW_ANSI_STDIO during the library build, although I don't know what the consequences are at runtime (could it cause a static or dynamic link failure in some reasonable scenarios?).

In development, we can fully switch to standard printf. We'll just have to ensure that we don't test with older versions of MingW. In all.sh, that means switching the minimum GCC version requirement from 6 (yielding Ubuntu 18.04) to 9 (meaning Ubuntu 20.04 or above, which for our current set of Docker images resolves to Ubuntu 24.04 with MingW 11.0.1, GCC 13).