RetroSearch Browse

Wed Sep 12 18:37:27 CEST 2012 · https://mail.python.org/pipermail/python-dev/2012-September/121704.html

Christian Heimes <lists at cheimes.de> wrote:
> Am 12.09.2012 16:22, schrieb Stefan Krah:
> > This is a false positive:
> 
> You might be right. But did you notice that there is much more code
> beyond the large comment block in PyLong_FromString()? There might be
> other code paths that push str beyond its limit.

Yes, I understand. My reasoning was different: The str[1] location Coverity
pointed out is a false positive. I checked other locations and they seem to
be okay, too.

Now, because there's so much code my first instinct would be not to touch
it unless there's a proven invalid access. This is to avoid subtle behavior
changes.

> My change adds an early opt out in an error case and doesn't cause a
> performance degradation. I'd have no hard feeling if you'd prefer a
> revert but I'd keep the modification as it causes no harm.

As far as I can see, only the error message is affected. Previously:

>>> int(b'', 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: ''

Now the fact that base=0 is converted to base=10 is lost:

>>> int(b'', 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 0: b''

No big deal of course, but still a change.

Stefan Krah

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-September/121704.html below:

[Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Fix out of bounds read in long_new() for empty bytes with an explicit base.