Author serhiy.storchaka
Recipients georg.brandl, mark.dickinson, nitishch, serhiy.storchaka, skrah
Date 2017-10-04.13:23:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507123412.47.0.213398074469.issue31619@psf.upfronthosting.co.za>
In-reply-to
Content
I missed the issue mentioned by Mark msg303331. I looked at the type of n, and okay, it is Py_ssize_t. But I forgot to check the type of digits and bits_per_char, and it is int. My fix doesn't guard from integer overflow.

The following PR fixes this. It also tries to guard against integer overflow in other place. Unfortunately there is yet one issue with that code. The guard works on 32-bit platform, where the precision of double is large than the size of Py_size_t. But on 64-bit platform it is possible that (Py_ssize_t)(digits * log_base_BASE[base]) takes the value not enough for writing the result of the parsing, because its lowest bits are lost.

I know that converting str to int with non-binary base has nonlinear complexity.
History
Date User Action Args
2017-10-04 13:23:32serhiy.storchakasetrecipients: + serhiy.storchaka, georg.brandl, mark.dickinson, skrah, nitishch
2017-10-04 13:23:32serhiy.storchakasetmessageid: <1507123412.47.0.213398074469.issue31619@psf.upfronthosting.co.za>
2017-10-04 13:23:32serhiy.storchakalinkissue31619 messages
2017-10-04 13:23:32serhiy.storchakacreate