That was suggested before, and since CPython 3.11 - c11 compiler is a requirement, see also discussion.
So why not c17? It’s essentially “c11 with bugfixes” and I believe all relevant compilers now support this standard.
That was suggested before, and since CPython 3.11 - c11 compiler is a requirement, see also discussion.
So why not c17? It’s essentially “c11 with bugfixes” and I believe all relevant compilers now support this standard.
What specific bug fixes are you interested in?
For me it’s, maybe, a very minor issue DR#471. This now adopted by cmath.
In the past whether we can do this or not is based on what the primary compiler on our Tier supported platforms require, and whether there are significant uses of other toolchains in non-tier platforms.
I don’t believe MSVC (Windows) supports more than C11 today based on Microsoft C/C++ language conformance | Microsoft Learn.
We’d want a compelling widely applicable reason with no well contained targeted workarounds available to adopt a more recent standard. Our C11 requirement is very recent, only happening two years ago for Python 3.11+.
They claim support for C17 since VS 2019.
My point was, that it’s actually not a new standard, it’s same C11.
Are those functions (cacosh
and ctanh
) even used in CPython? The cmath
module has its own implementation of all of its functions.
That’s true, but they return C99 (now actually C17) Annex G recommended results.
I was under the impression that specifying C17 over C11 did nothing on many compilers, as most of the fixes were backported.
How does it work on practice? Do compilers link to different math libraries or map cacosh
to different names depending on the C standard version? Or is there a global flag that affects its behavior? How is binary compatibility maintained between C11 and C17?
Glibc maintainers just unconditionally turn on C17 behaviour. An example: sourceware.org Git - glibc.git/commitdiff
I would expect same for others stdlib implementations. For example, referenced above MS blog post says: “Since C17 is essentially just a bug fix release of ISO C, with many defect reports being adopted, our support for C11 already includes all the relevant defect reports. At present, there are no differences between the C11 and C17 versions except for the __STDC_VERSION__
macro, which expands to 201112L
(for C11) and 201710L
(for C17).”
Out of interest, does Python 3.12 currently compile without errors if you switch it to use C17?
None (gcc-12) new warnings (only same as in the main, all for the decimal module).
diff --git a/configure b/configure
index c28c333550..5b1c71fa8a 100755
--- a/configure
+++ b/configure
@@ -9834,7 +9834,7 @@ fi
case $GCC in
yes)
- CFLAGS_NODIST="$CFLAGS_NODIST -std=c11"
+ CFLAGS_NODIST="$CFLAGS_NODIST -std=c17"
diff --git a/configure.ac b/configure.ac
index 9daace7179..d659a241a7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2525,7 +2525,7 @@ fi
case $GCC in
yes)
- CFLAGS_NODIST="$CFLAGS_NODIST -std=c11"
+ CFLAGS_NODIST="$CFLAGS_NODIST -std=c17"
PY_CHECK_CC_WARNING([enable], [extra], [if we can add -Wextra])
AS_VAR_IF([ac_cv_enable_extra_warning], [yes],
Then what is the difference? If the math library contains the C17 changes, you get them in any case.
I think it’s only in documentation. We claim C11-compatibility, but in reality: when we require a C11 compiler and stdlib - we usually got C17-compatible compiler and stdlib.