-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
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
Comments
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). |
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. |
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... |
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 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. |
… formats (pythonGH-128454) (cherry picked from commit 8d15058) Co-authored-by: Serhiy Storchaka <[email protected]>
… formats (pythonGH-128454) (cherry picked from commit 8d15058) Co-authored-by: Serhiy Storchaka <[email protected]>
…e formats (GH-128454) (GH-128538) (cherry picked from commit 8d15058) Co-authored-by: Serhiy Storchaka <[email protected]>
…e formats (GH-128454) (GH-128539) (cherry picked from commit 8d15058) Co-authored-by: Serhiy Storchaka <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
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:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: