Skip to content

Document that public headers target C11 and C++11 #129666

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
encukou opened this issue Feb 4, 2025 · 2 comments
Closed

Document that public headers target C11 and C++11 #129666

encukou opened this issue Feb 4, 2025 · 2 comments
Assignees
Labels
docs Documentation in the Doc dir tests Tests in the Lib/test dir topic-C-API

Comments

@encukou
Copy link
Member

encukou commented Feb 4, 2025

Our public documentation should say that you need C11 or C++11 to #include <Python.h>.

Internally, we need to be more lenient & careful (though we won’t promise upfront how much). It's not OK to just break C99 support or slightly out-of-spec compilers.
We should test as much as we can; the devguide should be updated with details.

API WG discussion/vote: capi-workgroup/decisions#30 (comment)
Discourse topic: https://discuss.python.org/t/python-3-14-headers-will-require-c11-and-c-11/79481

Linked PRs

Devguide PR

@encukou encukou added docs Documentation in the Doc dir tests Tests in the Lib/test dir topic-C-API labels Feb 4, 2025
@encukou encukou self-assigned this Feb 4, 2025
@rruuaanng
Copy link
Contributor

I have something to say:

It would be better if this could be managed through some switch macros to toggle between different C versions, This would make the migration process less abrupt, at least giving developers some options to choose from. I believe it's not just about migrating to C11. As far as I know, many are still using C99, and even though this has no impact on the migration results, C99 already fully meets the needs of some CPython developers. Although static assertions are really great, their absence can be compensated for by using a scanner.
(Although this will keep pace with the times.)

@encukou
Copy link
Member Author

encukou commented Feb 8, 2025

What kind of switch do you propose?
Static asserts, in particular, can be defined as nothing on compilers that don't support them.

If you can, please discuss on Discourse; here your comment won't be seen by as many people.

encukou added a commit that referenced this issue Feb 28, 2025
encukou added a commit to encukou/cpython that referenced this issue Feb 28, 2025
… to GCC/clang test_c[pp]ext tests (pythonGH-130686)"

This reverts commit 003e6d2.
encukou added a commit that referenced this issue Feb 28, 2025
…rors` to GCC/clang test_c[pp]ext tests (GH-130686)" (GH-130688)

This reverts commit 003e6d2.
encukou added a commit to encukou/cpython that referenced this issue Feb 28, 2025
encukou added a commit to encukou/cpython that referenced this issue Feb 28, 2025
encukou added a commit that referenced this issue Mar 4, 2025
…st_c[pp]ext tests (GH-130692)

Disable pedantic check for c++03 (unlimited API)

Also add a check for c++03 *limited* API, which passes in pedantic mode
after removing a comma in the `PySendResult` declaration, and allowing
`long long`.
@encukou encukou closed this as completed Mar 10, 2025
seehwan pushed a commit to seehwan/cpython that referenced this issue Apr 16, 2025
seehwan pushed a commit to seehwan/cpython that referenced this issue Apr 16, 2025
…-pedantic-errors` to GCC/clang test_c[pp]ext tests (pythonGH-130686)" (pythonGH-130688)

This reverts commit 003e6d2.
seehwan pushed a commit to seehwan/cpython that referenced this issue Apr 16, 2025
…ang test_c[pp]ext tests (pythonGH-130692)

Disable pedantic check for c++03 (unlimited API)

Also add a check for c++03 *limited* API, which passes in pedantic mode
after removing a comma in the `PySendResult` declaration, and allowing
`long long`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir tests Tests in the Lib/test dir topic-C-API
Projects
Status: Todo
Development

No branches or pull requests

2 participants