Christian Heimes added the comment:
You could be right. I didn't track all paths manually. All this bit shifting is
making my head dizzy... :)
Anyways I have sent you an invite for Coverity, so you can check the result
yourself. The Python test suite passes with assert(k 32); inside the
Mark Dickinson added the comment:
Ah, sorry; I see it. Fix on the way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23999
___
___
Mark Dickinson added the comment:
Looking more closely, the report doesn't make sense to me: `k` is the return
value from a call to `lo0bits`. From the source of `lo0bits`, I don't see any
way that `k` can be 32: it's always going to be in the range [0, 31].
Christian: do you have any more
Mark Dickinson added the comment:
Okay, so after looking more closely, this *still* looks like a false positive:
`lo0bits` *can* return 32, but only for an input of zero. In the code in
question, we're doing `k = lo0bits(y)`, so the only way we can get a `k` of
`32` is if `y = 0`. But the
Mark Dickinson added the comment:
saw no output
Bah; missed a bit. I saw no output when running the Python test suite, that
is. That's not definitive, of course.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23999
Mark Dickinson added the comment:
I'm pretty sure that our code was based on something rather more recent than
2001: it was the most recent version available at the time (around 2008?), and
it incorporates subsequent fixes from David Gay.
Please don't replace our dtoa.c with a current
New submission from Christian Heimes:
Coverity has found undefined behavior in dtoa.c:d2b(). lo0bits() can return 32
which z = 32, where z is an uint32. I've talked to doku at PyCon. He
suggested to update dtoa.c to a more recent version. Our copy is based on a
version from 2001. There are
