[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing
New submission from Enrico Zini <enrico@enricozini.org>: In https://docs.python.org/3.9/c-api/arg.html, in the documentation for parsing argument, there is: s# (str, read-only bytes-like object) [const char *, int or Py_ssize_t] In my amd64 system, `Py_ssize_t` is a different type than `int`, and passing a `Py_ssize_t` causes undefine behaviour. I assume this has been switched to an `int` in the API, and that thisinstance of the documentation has not been updated accordingly. At the bottom of the page in the documentation of `Py_BuildValue`, `s#` is correctly documented as using an `int` and no `Py_ssize_t`, for example. ---------- assignee: docs@python components: Documentation messages: 346974 nosy: docs@python, enrico priority: normal severity: normal status: open title: Incorrect documentation for `s#` arguments in C API argument parsing versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Inada Naoki <songofacandy@gmail.com> added the comment: See note in https://docs.python.org/3.9/c-api/arg.html#strings-and-buffers """ Note: For all # variants of formats (s#, y#, etc.), the type of the length argument (int or Py_ssize_t) is controlled by defining the macro PY_SSIZE_T_CLEAN before including Python.h. If the macro was defined, length is a Py_ssize_t rather than an int. This behavior will change in a future Python version to only support Py_ssize_t and drop int support. It is best to always define PY_SSIZE_T_CLEAN. """ ---------- nosy: +inada.naoki _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Enrico Zini <enrico@enricozini.org> added the comment: Oh! Fair enough, I had missed it. Does the note also involve `Py_BuildValue`? If so, the documentation of `Py_BuildValue` should probably be updated; if not, I think it would be clearer if the note mentioned that it only applies to parsing, not building, values. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Inada Naoki <songofacandy@gmail.com> added the comment:
Oh! Fair enough, I had missed it. Does the note also involve `Py_BuildValue`? If so, the documentation of `Py_BuildValue` should probably be updated; if not, I think it would be clearer if the note mentioned that it only applies to parsing, not building, values.
Yes, this is same to Py_BuildValue. The document of Py_BuildValue should be `int or Py_ssize_t` too. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Change by STINNER Victor <vstinner@python.org>: ---------- components: +C API _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Change by Serhiy Storchaka <storchaka+cpython@gmail.com>: ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 2.7 -Python 3.5, Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Change by Iustin Pop <iustin@k1024.org>: ---------- keywords: +patch pull_requests: +17566 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/17478 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
Inada Naoki <songofacandy@gmail.com> added the comment: Fixed via GH-18663. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue37465> _______________________________________
participants (5)
-
Enrico Zini -
Inada Naoki
-
Iustin Pop
-
Serhiy Storchaka
-
STINNER Victor