-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Python.h contains intermingled declarations #81372
Comments
When compiled with GCC's -Werror=declaration-after-statement ("intermingled declarations" in PEP-7), cpython/abstract.h (included from <Python.h>) errors on vectorcall helper functions added in 3.8.0 Beta 1. It's well within our rights to ignore this: since 3.6 we require intermingled declarations. Dear Release Manager, should we patch 3.8 to avoid this? The patch is simple, and it would give projects that we(re) dutifully tested with the Alphas one more release to adapt. I don't think it's worth changing for 3.9 (but if we do we should test it). |
Correction:
Anyway, we can usually take care of open-source stuff. Only take it as a litmus test for codebases we don't know about. |
PR 13887 is fine but I would prefer to still be able to use C99 style for variable declarations. More generally, I don't think that variable declaration is the only issue: static inline function is a new shiny thing which can cause other issues with some C compilers. So I propose a different approach, bpo-37194: "Move new vector private declarations to the internal C API". |
Should we revert these inline functions back to macros? |
It's not clear from PEP-7 if we require intermingled declarations only when compiling CPython itself, or also for external packages that include CPython headers. It would be prudent to stay C89-compatible for non-internal header files. |
I've removed -Wdeclaration-after-statement in upstream pygobject: https://gitlab.gnome.org/GNOME/pygobject/merge_requests/119 |
Thanks! Enjoy C99! :-) IMHO C99 with variables in the middle of a function helps to write more reliable code: we better control the scope of a variable. It reduces the risk of using an uninitialized variable. |
Petr Viktorin fixed the issue, thanks ;-) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: