Hello,
The C API WG approved that the public headers (Python.h) should be usable with C11 and C++11. Previously, the target C/C++ standard versions were unclear.
In practice, we test on PEP-11 platforms and react to users who report regressions for other platforms/configurations. I expect that this won’t change.[1]
We already use a C11 feature – an anonymous union – since 3.13. All relevant compilers support this. (If you compile for C99 in a “standards compatibility checking mode” (gcc -pedantic, MSVC /W4), we silence the resulting warning.)
Note that Python itself requires C11 to buildsince 3.11. This is about the headers used for third-party extension modules.
Well, that’s the public message. Internally, we need to be more lenient & careful (though we won’t promise upfront how much). Core devs should add new features individually, as needed, each with some care when it’s first introduced. Ideally, check with the C API WG before adding something new to public headers (./Include/ except ./Include/internal/):
new anonymous structures and unions
new uses of atomic types
_Alignas
_Static_assert
_Noreturn
_Bool
If you explicitly tell your compiler to check for C99 compatibility, we might tell you to not do that and only report actual incompatibilities. Or we might silence the warnings instead. That’s for another discussion. ↩︎
If anyone is curious about the impact this might have on downstream packages, I recommend looking at the C compilers section of the “toolchain roadmap” in the SciPy docs: Toolchain Roadmap — SciPy v1.15.1 Manual
Hah, glad that my ramblings[1] on this still serve some purpose!
I’ve been loosely following conformance developments, and on the MSVC side, it’s been a while since experimental atomics support was announced, and their docs indicate that it’s still experimental – perhaps something to keep in mind when wanting to add atomics.
<threads.h> is supported since VS 17.8, but <complex.h>support is still nowhere to be seen (not relevant for CPython anyway I guess). vNext briefly seemed to move into view last year, but things have gone dead quiet again since then.
If this feature could be made optional through a macro switch (e.g., C11_HEADER), that would be ideal (naming is always a challenge). Not everyone uses C11—most C environments remain on ANSI and C99. Static assertions are great, but not everyone needs them. In some constrained environments, static analyzers are typically used to identify potential risks. For environments using C99, no-op macros can be used to maintain code consistency.
I get where you’re coming from, and I’d give you that option if it was easy.
For static assertions, we can definitely define them as no-ops. It’s more complicated with anonymous structs/unions, which are very helpful for adding features/optimizations while keeping API compatibility – we’re at the point where not having them legitimately blocks CPython development. See our current use – which also shows that to use Python 3.13, you already need a compiler that supports this C11 feature. What would a macro like C11_HEADER do here?
Perhaps more importantly, I don’t think we can properly test & support a macro like C11_HEADER. Not just in CI: ideally, contributors to CPython wouldn’t need to think about avoiding C11 features, which is getting harder and harder to do – all relevant compilers support C11[1], and to disable them you have to specifically ask the compiler for a C99 mode.
So, the decision is to support C11, test with C11, and tell people to use C11 to avoid issues. We also keep C99 working & tested where it’s reasonable – but users should be prepared to do some extra testing[2], and maybe add some workarounds, version pins or patches.
It seems to me that most of today’s uses of supporting a C99 mode are … ensuring that your library works with other software that supports/requires C99 mode. And that’s the extra testing I’m talking about here. ↩︎
