René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[C API] Avoid \"const PyObject*\" type","articleBody":"When I converted ``Py_REFCNT()``, ``Py_TYPE()`` and ``Py_SIZE()`` macros to static inline functions (issue #83754), I chose ``const PyObject*`` for their argument because these macros don't modify any member of the PyObject structure. When the Py_IS_TYPE() function was added, it followed the trend (commit 8767ce92d24d3687405848442e6c67cf0af1c657). The ``_PyObject_CAST_CONST()`` macro was added to easily convert any pointer to ``const PyObject*`` for these macros expecting ``const PyObject*``.\r\n\r\nThe problem is that passing ``PyObject*`` to one of these functions emits a compiler warning using ``gcc -Wcast-qual``. The ``_PyObject_CAST_CONST()`` doesn't make the warning quiet.\r\n\r\nExample explaining the issue:\r\n\r\n```c\r\nstatic inline int value(int *p) { return *p; }\r\n#define value(p) value((int*)(p))\r\n\r\nint main()\r\n{\r\n    int x = 1;\r\n    const int *p = \u0026x;\r\n    return value(p);\r\n}\r\n```\r\n\r\nOutput:\r\n\r\n```sh\r\n$ gcc x.c -Wcast-qual -o x \u0026\u0026 ./x; echo $?\r\nx.c: In function 'main':\r\nx.c:2:24: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]\r\n    2 | #define value(p) value((int*)(p))\r\n      |                        ^\r\nx.c:8:12: note: in expansion of macro 'value'\r\n    8 |     return value(p);\r\n      |            ^~~~~\r\n1\r\n```\r\n\r\nIn practice, the problem was that building a C extension (which includes ``\u003cPython.h\u003e``) with ``gcc -Wcast-qual -Werror`` on Python 3.10 failed with an error on Py_IS_TYPE() implemented as:\r\n\r\n```c\r\nstatic inline int Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {\r\n    return Py_TYPE(ob) == type;\r\n}\r\n#define Py_IS_TYPE(ob, type) Py_IS_TYPE(_PyObject_CAST_CONST(ob), type)\r\n```\r\n\r\nSee the issue #88544 for the compiler error. I removed the Py_TYPE() call in Py_IS_TYPE() to work around the issue:\r\n\r\n```c\r\nstatic inline int Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {\r\n    // bpo-44378: Don't use Py_TYPE() since Py_TYPE() requires a non-const\r\n    // object.\r\n    return ob-\u003eob_type == type;\r\n}\r\n#define Py_IS_TYPE(ob, type) Py_IS_TYPE(_PyObject_CAST_CONST(ob), type)\r\n```\r\n\r\nBut this problem strikes back when I try to convert unicodeobject.h macros to static inline functions for PEP 670 which removes the cast to ``PyObject*`` in the limited C API version 3.11: see PR #91696 and PR #91705. For example, _Py_strhex_with_sep() and _Py_strhex_bytes_with_sep() function get a ``const PyObject*`` argument and use PyUnicode C functions like PyUnicode_READY(), PyUnicode_KIND() and PyUnicode_READ_CHAR(), but these PyUnicode functions expect ``PyObject*``: the ``const`` qualifier is lost. If Python/pystrhex.c is built with ``gcc -Wcast-qual``, gcc emits warnings on PyUnicode_KIND() and PyUnicode_READ_CHAR() calls. That's just an example of problem which can happen in C extensions as well.\r\n\r\nTo avoid these problems, I propose to avoid ``const PyObject*`` in Python: only use ``PyObject*``.","author":{"url":"https://github.com/vstinner","@type":"Person","name":"vstinner"},"datePublished":"2022-04-20T23:37:07.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/91768/cpython/issues/91768"}