Skip to content

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

Closed

Description

@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.

Activity

  1. added 2 commits that reference this issue on May 15, 2022
  2. petere commented on May 19, 2022

    @petere
    Contributor

    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. ;-)

  3. erlend-aasland commented on May 19, 2022

    @erlend-aasland
    Contributor

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

  4. vstinner commented on May 19, 2022

    @vstinner
    MemberAuthor

    Issue fixed by #92783

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions