Skip to content

Clarify that the signed number convertors to PyArg_ParseTuple... *do* overflow checking #77214

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

Closed
anntzer mannequin opened this issue Mar 9, 2018 · 4 comments
Closed
Assignees
Labels
docs Documentation in the Doc dir

Comments

@anntzer
Copy link
Mannequin

anntzer mannequin commented Mar 9, 2018

BPO 33033
Nosy @serhiy-storchaka, @anntzer

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 = None
created_at = <Date 2018-03-09.00:47:58.411>
labels = ['docs']
title = 'Clarify that the signed number convertors to PyArg_ParseTuple... *do* overflow checking'
updated_at = <Date 2018-03-09.09:34:18.737>
user = 'https://github.com/anntzer'

bugs.python.org fields:

activity = <Date 2018-03-09.09:34:18.737>
actor = 'Antony.Lee'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2018-03-09.00:47:58.411>
creator = 'Antony.Lee'
dependencies = []
files = []
hgrepos = []
issue_num = 33033
keywords = []
message_count = 3.0
messages = ['313471', '313474', '313478']
nosy_count = 3.0
nosy_names = ['docs@python', 'serhiy.storchaka', 'Antony.Lee']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue33033'
versions = ['Python 3.6']

Linked PRs

@anntzer
Copy link
Mannequin Author

anntzer mannequin commented Mar 9, 2018

At https://docs.python.org/3/c-api/arg.html#numbers, it is explicitly documented that the unsigned number convertors do not perform overflow checking. Implicitly, this suggests that the signed convertors *do* perform overflow checking, which they indeed do; but it would be nice to document this behavior explicitly (as overflow checking is not always expected of C-level functions).

@anntzer anntzer mannequin assigned docspython Mar 9, 2018
@anntzer anntzer mannequin added the docs Documentation in the Doc dir label Mar 9, 2018
@serhiy-storchaka
Copy link
Member

This doesn't look a good idea to me. It is implied that all checks are performed. For example it is implied that an error will be raised if the argument is of wrong type. I think that adding "with overflow checking" to every converting from a Python integer will just clutter the documentation.

@anntzer
Copy link
Mannequin Author

anntzer mannequin commented Mar 9, 2018

One could just add, immediately below the "Numbers" section, something like: "The signed convertors (b, h, i, ...) perform overflow checking. The unsigned convertors (B, H, I, ...) do not." That would actually be shorter than the current version, which repeats the second half for each unsigned entry...

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@serhiy-storchaka
Copy link
Member

It is worse -- right after all format units there is a paragraph which states that no proper range checking is done:

It is possible to pass "long" integers (integers whose value exceeds the
platform's :c:macro:`LONG_MAX`) however no proper range checking is done --- the
most significant bits are silently truncated when the receiving field is too
small to receive the value (actually, the semantics are inherited from downcasts
in C --- your mileage may vary).

It is likely dates to the times when there were separate types int and long and conversion from long to int truncated value. This is absolutely false now.

I think that we should add a paragraph at the beginning of the "Numbers" section (similar to the paragraph at the beginning of the "Strings and buffers" section) which clarifies general rules: what types are accepted, what conversions are performed and how overflow is handled.

@serhiy-storchaka serhiy-storchaka self-assigned this Jan 3, 2025
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue Jan 3, 2025
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 6, 2025
… formats (pythonGH-128454)

(cherry picked from commit 8d15058)

Co-authored-by: Serhiy Storchaka <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 6, 2025
… formats (pythonGH-128454)

(cherry picked from commit 8d15058)

Co-authored-by: Serhiy Storchaka <[email protected]>
serhiy-storchaka added a commit that referenced this issue Jan 6, 2025
…e formats (GH-128454) (GH-128538)

(cherry picked from commit 8d15058)

Co-authored-by: Serhiy Storchaka <[email protected]>
serhiy-storchaka added a commit that referenced this issue Jan 6, 2025
…e formats (GH-128454) (GH-128539)

(cherry picked from commit 8d15058)

Co-authored-by: Serhiy Storchaka <[email protected]>
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this issue Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

No branches or pull requests

1 participant