Florent Xicluna florent.xicl...@gmail.com added the comment:
Fixed with r83859 (on 3.2).
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
___
___
Python-bugs-list
New submission from Alex alex.gay...@gmail.com:
In Objects/stringlib/fastsearch.h the lines:
if (!STRINGLIB_BLOOM(mask, s[i-1]))
and
if (!STRINGLIB_BLOOM(mask, s[i-1]))
can read beyond the front of the array that is passed to it when the loop
enters with i =
Changes by Antoine Pitrou pit...@free.fr:
--
components: +Interpreter Core
nosy: +flox
priority: - normal
stage: - needs patch
type: - behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
Florent Xicluna florent.xicl...@gmail.com added the comment:
I guess we don't have the same issue with the find() implementation?
if (!STRINGLIB_BLOOM(mask, s[i+m]))
Because:
* len(s) = n = (w + m)
* the loop condition is (i = w)
== s[w+m] is beyond the array, but it is '\0' probably
Is
Alex alex.gay...@gmail.com added the comment:
Yes, as the comment of the top of the file notes, reading to s[n] (where n ==
len(s)) is safe because strings are null padded.
--
___
Python tracker rep...@bugs.python.org
Florent Xicluna florent.xicl...@gmail.com added the comment:
This patch should fix it.
Since there's no failure, I don't find any test to add.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file17078/issue8530_rfind.diff
Antoine Pitrou pit...@free.fr added the comment:
I can't manage to trigger any crash on a Linux machine, so I think we'll live
without a test.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
Antoine Pitrou pit...@free.fr added the comment:
Of course your patch might slow down the loop, so perhaps you want to run some
benchmarks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
Changes by Antoine Pitrou pit...@free.fr:
--
versions: -Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
___
___
Benjamin Peterson benja...@python.org added the comment:
Why add a bounds check if it can't be caused to fail. How about just a comment?
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
Alex alex.gay...@gmail.com added the comment:
Well, the fact that it hasn't been shown to fail doesn't mean it can't fail.
It relies on reading undefined memory, which is usually bad ;). However, since
we're at i=0, regardless of what we add to the value it's going to end up
terminating the
Antoine Pitrou pit...@free.fr added the comment:
It could read into an invalid page and segfault. It depends on specifics of the
memory allocator.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8530
13 matches
Mail list logo
