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.

Sign up for GitHub

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

Jump to bottom

Remove "w" format of PyParse_ParseTuple() #53096

Closed
vstinner opened this issue May 29, 2010 · 8 comments
Closed

Remove "w" format of PyParse_ParseTuple() #53096

vstinner opened this issue May 29, 2010 · 8 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@vstinner
Copy link
Member

BPO 8850
Nosy @loewis, @pitrou, @vstinner
Files
  • remove_w_format.patch
  • remove_w_format-2.patch
    		•

    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 2010-06-25.00:03:40.859>
created_at = <Date 2010-05-29.02:24:18.472>
labels = ['interpreter-core']
title = 'Remove "w" format of PyParse_ParseTuple()'
updated_at = <Date 2010-06-25.00:03:40.858>
user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2010-06-25.00:03:40.858>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2010-06-25.00:03:40.859>
closer = 'vstinner'
components = ['Interpreter Core']
creation = <Date 2010-05-29.02:24:18.472>
creator = 'vstinner'
dependencies = []
files = ['17571', '17670']
hgrepos = []
issue_num = 8850
keywords = ['patch']
message_count = 8.0
messages = ['106702', '107193', '107324', '107367', '107755', '107812', '107829', '108572']
nosy_count = 3.0
nosy_names = ['loewis', 'pitrou', 'vstinner']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue8850'
versions = ['Python 3.2']
    @vstinner
    Copy link
    Member Author

    "w" format is dangerous because it doesn't give the size of the buffer: the caller may write outside the buffer (buffer overflow).

    "w*" and "w#" formats are fine.

    It looks like "w" format is not used in trunk nor py3k (only w# and w*).

    @vstinner vstinner added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label May 29, 2010
    @vstinner
    Copy link
    Member Author

    vstinner commented Jun 6, 2010

    Attached patch removes "w" format, cleanups the code for "w*" and "w#" formats, and update the documentation.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 8, 2010

    I'd point out that "w#" is mostly useless too. It's supposed to return a read-write buffer, but as the doc says it also doesn't support "mutable objects", since it isn't able to properly lock/pin the buffer; therefore it probably doesn't support anything useful.

    @vstinner
    Copy link
    Member Author

    vstinner commented Jun 9, 2010

    See also bpo-8592: 'y' does not check for embedded NUL bytes.

    @vstinner
    Copy link
    Member Author

    "w#" is not only useless but also not used in py3k source code. "w" is also not used. Only "w*" is used by fnctl and socket modules.

    The problem with w# is that the caller cannot "release" the buffer and so we cannot lock the buffer. I don't know exactly what happens if you get a pointer to a bytearray, release the GIL and then use it, whereas another thread modifies and/or destroys the bytearray object. (I suppose that something bad will happen, like a segfault)

    @vstinner
    Copy link
    Member Author

    New (improved) version of the patch:

    • Remove also "w#" format
    • Write tests for "w*" format

    @vstinner
    Copy link
    Member Author

    See also bpo-8926.

    @vstinner
    Copy link
    Member Author

    Commited to 3.2 (r82208), blocked in 3.1 (r82209).

    @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
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @vstinner @pitrou