Skip to content
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

Incorrect documentation for s# arguments in C API argument parsing #81646

Closed
enrico mannequin opened this issue Jul 1, 2019 · 5 comments
Closed

Incorrect documentation for s# arguments in C API argument parsing #81646

enrico mannequin opened this issue Jul 1, 2019 · 5 comments
Labels
3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes docs Documentation in the Doc dir easy topic-C-API type-feature A feature request or enhancement

Comments

@enrico
Copy link
Mannequin

enrico mannequin commented Jul 1, 2019

BPO 37465
Nosy @methane
PRs
  • bpo-37465: Parsing: all of s/y/z take a Py_ssize_t #17478
  • 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:

    assignee = None
    closed_at = <Date 2020-04-23.05:20:33.359>
    created_at = <Date 2019-07-01.08:20:20.624>
    labels = ['easy', '3.7', '3.8', '3.9', 'expert-C-API', 'type-feature', 'docs']
    title = 'Incorrect documentation for `s#` arguments in C API argument parsing'
    updated_at = <Date 2020-04-23.05:20:33.358>
    user = 'https://bugs.python.org/enrico'

    bugs.python.org fields:

    activity = <Date 2020-04-23.05:20:33.358>
    actor = 'methane'
    assignee = 'docs@python'
    closed = True
    closed_date = <Date 2020-04-23.05:20:33.359>
    closer = 'methane'
    components = ['Documentation', 'C API']
    creation = <Date 2019-07-01.08:20:20.624>
    creator = 'enrico'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 37465
    keywords = ['patch', 'easy']
    message_count = 5.0
    messages = ['346974', '346976', '346982', '347102', '367078']
    nosy_count = 3.0
    nosy_names = ['methane', 'docs@python', 'enrico']
    pr_nums = ['17478']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue37465'
    versions = ['Python 2.7', 'Python 3.7', 'Python 3.8', 'Python 3.9']

    @enrico
    Copy link
    Mannequin Author

    enrico mannequin commented Jul 1, 2019

    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.

    @enrico enrico mannequin added 3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes labels Jul 1, 2019
    @enrico enrico mannequin assigned docspython Jul 1, 2019
    @enrico enrico mannequin added the docs Documentation in the Doc dir label Jul 1, 2019
    @methane
    Copy link
    Member

    methane commented Jul 1, 2019

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

    @enrico
    Copy link
    Mannequin Author

    enrico mannequin commented Jul 1, 2019

    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.

    @methane
    Copy link
    Member

    methane commented Jul 2, 2019

    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.

    @serhiy-storchaka serhiy-storchaka added easy type-feature A feature request or enhancement labels Dec 10, 2019
    @methane
    Copy link
    Member

    methane commented Apr 23, 2020

    Fixed via #62863.

    @methane methane closed this as completed Apr 23, 2020
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes docs Documentation in the Doc dir easy topic-C-API type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants