This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2012年06月04日 00:32 by rfk, last changed 2022年04月11日 14:57 by admin.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| PyLong_FromString-doc.patch | rfk, 2012年06月04日 00:32 | review | ||
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 26774 | open | Cryvate, 2021年06月17日 18:51 | |
| Messages (3) | |||
|---|---|---|---|
| msg162242 - (view) | Author: Ryan Kelly (rfk) | Date: 2012年06月04日 00:32 | |
PyLong_FromString will raise a ValueError if the given string doesn't contain a null byte after the digits. For example, this will result in a ValueError
char *pend;
PyLong_FromString("1234 extra", &pend, 10)
While this will successfully read the number and set the pointer to the extra data:
char *pend;
PyLong_FromString("12340円extra", &pend, 10)
The requirement for a null-terminated string of digits is not clear from the docs. Suggested re-wording attached.
|
|||
| msg212559 - (view) | Author: Chris Angelico (Rosuav) * | Date: 2014年03月02日 15:23 | |
Patch doesn't apply to current Python trunk (18 months later). Do you know what version you wrote this against? The current wording is different. |
|||
| msg396032 - (view) | Author: Josh Rosenberg (josh.r) * (Python triager) | Date: 2021年06月18日 04:13 | |
The description is nonsensical as is; not sure the patch goes far enough. C-style strings are *defined* to end at the NUL terminator; if it really needs a NUL after the int, saying it "points to the first character which follows the representation of the number" is highly misleading; the NUL isn't logically a character in the C-string way of looking at things. The patch is also wrong; the digits need not end in a NUL byte (trailing whitespace is allowed). AFAICT, the function really uses pend for two purposes: 1. If it succeeds in parsing, then pend reports the end of the string, nothing else 2. If it fails, because the string is not a legal input (contains non-numeric, or non-leading/terminal whitespace or whatever), pend tells you where the first violation character that couldn't be massaged to meet the rules for int() occurred. #1 is a mostly useless bit of info (strlen would be equally informative, and if the value parsed, you rarely care how long it was anyway), so pend is, practically speaking, solely for error-checking/reporting. The rewrite should basically say what is allowed (making it clear anything beyond the single parsable integer value with optional leading/trailing whitespace is illegal), and making it clear that pend always points to the end of the string on success (not just after the representation of the number, it's after the trailing whitespace too), and on failure indicates where parsing failed. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:31 | admin | set | github: 59200 |
| 2021年06月18日 04:13:42 | josh.r | set | nosy:
+ josh.r messages: + msg396032 |
| 2021年06月17日 18:51:27 | Cryvate | set | nosy:
+ Cryvate pull_requests: + pull_request25360 stage: patch review |
| 2021年06月17日 13:37:54 | cryvate | set | nosy:
+ cryvate |
| 2021年06月17日 13:05:26 | iritkatriel | set | keywords:
+ easy type: enhancement versions: + Python 3.11 |
| 2014年03月02日 15:23:13 | Rosuav | set | nosy:
+ Rosuav messages: + msg212559 |
| 2012年06月04日 00:32:53 | rfk | create | |