Python 3.11 C API is not compatible with ISO C90: ISO C90 forbids mixed declarations and code

[vstinner]

On Fedora, building the xen package with Python 3.11 fails with C compiler errors like:

In file included from /usr/include/python3.11/unicodeobject.h:1042,
                 from /usr/include/python3.11/Python.h:51,
                 from xen/lowlevel/xc/xc.c:7:
/usr/include/python3.11/cpython/unicodeobject.h: In function ‘_PyUnicode_NONCOMPACT_DATA’:
/usr/include/python3.11/cpython/unicodeobject.h:330:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  330 |     void *data = _PyUnicodeObject_CAST(op)->data.any;
      |     ^~~~
/usr/include/python3.11/cpython/unicodeobject.h: In function ‘PyUnicode_READ_CHAR’:
/usr/include/python3.11/cpython/unicodeobject.h:414:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  414 |     unsigned int kind = PyUnicode_KIND(unicode);
      |     ^~~~~~~~
/usr/include/python3.11/cpython/unicodeobject.h: In function ‘PyUnicode_MAX_CHAR_VALUE’:
/usr/include/python3.11/cpython/unicodeobject.h:439:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  439 |     unsigned int kind = PyUnicode_KIND(op);
      |     ^~~~~~~~
In file included from /usr/include/python3.11/weakrefobject.h:35,
                 from /usr/include/python3.11/Python.h:83:
/usr/include/python3.11/cpython/weakrefobject.h: In function ‘PyWeakref_GET_OBJECT’:
/usr/include/python3.11/cpython/weakrefobject.h:41:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
   41 |     PyWeakReference *ref = _Py_CAST(PyWeakReference*, ref_obj);
      |     ^~~~~~~~~~~~~~~
In file included from /usr/include/python3.11/abstract.h:866,
                 from /usr/include/python3.11/Python.h:100:
/usr/include/python3.11/cpython/abstract.h: In function ‘PyObject_CallMethodOneArg’:
/usr/include/python3.11/cpython/abstract.h:116:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  116 |     size_t nargsf = 2 | PY_VECTORCALL_ARGUMENTS_OFFSET;
      |     ^~~~~~
/usr/include/python3.11/cpython/abstract.h: In function ‘_PyObject_CallMethodIdOneArg’:
/usr/include/python3.11/cpython/abstract.h:165:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  165 |     size_t nargsf = 2 | PY_VECTORCALL_ARGUMENTS_OFFSET;
      |     ^~~~~~
cc1: all warnings being treated as errors

See: https://bugzilla.redhat.com/show_bug.cgi?id=2084008#c0

In Python 3.11, PEP 670 converts multiple macros to static inline functions. A C11 compiler (without optional features) is now required to build Python 3.11.

In 2022, most C compilers support C99 which supports mixed declarations and code, so I don't understand why people insist on using -Werror=declaration-after-statement. Maybe it's more a coding style, than a technical requirement. Or maybe it prevented compiler errors on old C compilers a few years ago, and nobody considered removing the compiler flag since that old time.

We can try to stay somehow compatible with ISO C90 in Python 3.11. Avoid "mixed declarations and code" in static inline functions requires minimum changes and so IMO is acceptable.

[petere]

In 2022, most C compilers support C99 which supports mixed declarations and code, so I don't understand why people insist on using -Werror=declaration-after-statement. Maybe it's more a coding style, than a technical requirement. Or maybe it prevented compiler errors on old C compilers a few years ago, and nobody considered removing the compiler flag since that old time.

PostgreSQL is another package that uses -Wdeclaration-after-statement and as a consequence occasionally runs afoul of Python header files. As you say, it's not a technical requirement but more a desire to maintain a consistent style from the before-C99 days. Maybe this is a battle we (PostgreSQL) will lose some day, but in the meantime, poking the Python devs once a year is less work then re-litigating the code style choice among the PostgreSQL devs. ;-)

[erlend-aasland]

Are there more intermingled declarations left in the public headers, Victor? If not, we can close this issue :)

[vstinner]

Issue fixed by #92783