Hello,
For Python 3.11, we decided that CPython uses the C11 standard (see PEP 7). As far as we know, all relevant compilers support C11.
However, I found out that our CI isn’t all set up to use C11, so we can’t actually use all the features yet.
So, in practice, the features we can use are limited by how the CI & buildbots are set up. I don’t think that’s a terrible situation. It’s vaguely defined, but for platforms/configs that don’t have a stable buildbot, build with C11 and you’re safe.
But maybe we want to change it, so we don’t need to work around things that have been standardized for a decade?
Specifically, I wanted to use `alignof(max_align_t)`, but `alignof` and `max_align_t` is not available on all CIs runs and buildbots. I worked around this.
I asked autotools for a ALIGNOF_MAX_ALIGN_T, add to the list of hardcoded ALIGNOF_* values for Windows, add and test a fallback to alignof(long double) if max_align_t isn’t available. Instead of alignof I used _Alignof – compilers support the actual functionality and their C11 mode only adds the convenience macro (which is backwards incompatible).
If you think this particular case can be done better, comment at #103509 or open a new issue.
Opening up Python in Microsoft Visual Studio (the tool that has a GUI for the XMLs in PCBuild/ – not VS Code), I can see that we use “Legacy MSVC” rather than “ISO C11” (see a screenshot in the docs). Do we want to change that?
There are also *nix buildbots that would need changing, but I haven’t looked into how to do it.
Not all of our settings flow through into VS properly (VS reads those settings out of project files directly, while MSBuild allows shared properties files to be “included” and we make use of this), but I believe in this case it’s correct.
The main thing that we’d be enforcing is a minimum compiler version. Last time we pushed the minimum up, core devs complained that we broke their setup and they didn’t want to upgrade their compilers. (I don’t recall who, it’s probably on a bug somewhere.)
I don’t have any other concerns with enabling the compiler mode, except we must require that our header files do not require C11 and must also work in C++.
I don’t see why not, at least for 3.12+. I’m not sure if we’d want to change 3.11 at this point in its lifecycle.
What kind of changes to which builders? For the most part, any changes would need to be done by their owners unless we’re just talking about things like arguments to ./configure.
We do require C++ compatibility for headers. AFAIK there’s even a test for it, but it’s pretty limited (and the distutils removal didn’t help).
Not requiring C11 for headers is another thing. What should we require? C99? Or C89 with select C99 features, as in 3.10?
We should document that in PEP 7 and test it, otherwise someone’s bound to break it. I guess the current CI and buildbot settings are keeping us in line somewhat, but that’s not ideal.
Yes, definitely.You did mean 3.13+, right?
I’ll not look into that until/unless we decide it’s a good idea.
I think we have to require C89 with very very few select C99 features, unless we also start requiring a particular C++ standard as well. There’s very little overlap or consistency between things added post-1990 to each language.
It shouldn’t be an onerous requirement, unless people want to get way too clever with macros/inline functions. And I think we’re best to not get way too clever with those.
The problem here is that you can’t really test this. A guideline without tests isn’t very useful.
We could be compatible with both C99 and C++. That’s testable, separately. And so is C11 and C++ (which would IMO be a better choice, since C11 removed the C99 features MSVC doesn’t support.)
It’s useful enough for winning arguments on the bug tracker, even if we don’t discover the issue until later. I’ve had to argue the point before.
Appeal to Authority (in this case, our guideline) often wins where Appeal on-behalf-of-actual-users just extends the argument.
Sure, and yeah C11 is probably easier. But there’s no reason why our C users should be pushed into a later compiler version just to include our headers either.
Basically, C89 + // comments is as far as I’d go. And I could be convinced that we don’t need // comments in our headers either. Designated initializers are a non-starter, as they push the C++ requirement too high, IMHO. What other features are left to quibble over?
Incidentally, we have a couple of C++ files as part of the Windows build, so compilation should break if anyone introduces unsupported things into the headers. They build with C++20 enabled in CI though (if available), because argument clinic requires it, so they’re only half a test.
Looks like the best path forward is testing both C11 and (some specific version of) C++, while documenting C89 plus a list extensions.
PEP 7 currently lists C11, so it would need changing for the argument to authority.
I have the tests on my TODO list. I probably won’t get to them any time soon, but when I do I’ll know what to do! Of course, anyone is free to work on them (and I can mentor someone who knows C & shell).
There are fixed-width integers and static inline functions, but I don’t think those are up for quibbling over :)
