You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PyLong_FromString() does not always set *pend on error #110865
According to the documentation, PyLong_FromString() sets *pend (if pend is not NULL) to the first character that could not be processed on error. But it does not do this in the following cases:
base is invalid (not 0 or in range from 2 to 36).
Binary base number exceeds sys.maxsize bits.
Decimal number exceeds the limit of digits sys.get_int_max_str_digits().
Other base numbers also have limits.
Memory allocation error.
User presses Ctrl-C when _pylong.int_from_string() is used.
The workaround is to initialize the pointer to some known value, for example the start of the string or NULL before using PyLong_FromString(). If initialize it to NULL, we can distinguish ValueError raised for invalid base or exceeding the sys.get_int_max_str_digits() limit from ValueError raised for invalid string content.
We should either document this and require initialization of the end pointer, or always set it on error in PyLong_FromString(). The latter is a potentially breaking change, because it can override the sentinel value used in the user code. But the former looks like bad design.
Setting it to NULL might make existing code crash, and does not follow the current documentation. IMO, that makes it a no-go.
So, IMO it should be set to the start of the string.
Distinguishing e.g. ValueError from invalid base from ValueError from string contents doesn't seem that useful to me.
If it is useful, IMO we should add specialized API with a richer set of errors states it can report.
Activity
encukou commentedon Oct 17, 2023
Setting it to
NULLmight make existing code crash, and does not follow the current documentation. IMO, that makes it a no-go.So, IMO it should be set to the start of the string.
Distinguishing e.g.
ValueErrorfrom invalid base fromValueErrorfrom string contents doesn't seem that useful to me.If it is useful, IMO we should add specialized API with a richer set of errors states it can report.