Red Hat Bugzilla – Bug 141000
strtold uses uninitialized array element
Last modified: 2007-11-30 17:10:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
uses an unintialized array element. [There are 19 zeroes betweeen the
decimal point and the '1' in the first argument.] The uninit is
n0 = num[densize];
with 3==densize. The 'while' loop at line 1507 is skipped (the
condition is false the first and only time), then
for (i = densize; num[i] == 0 && i >= 0; --i)
return round_and_return (retval, exponent - 1, negative,
quot, BITS_PER_MP_LIMB - 1 - used,
more_bits || i >= 0);
The condition "num[i] == 0" uses the uninit value num[densize]. The
result is an unpredictable value in "i", so the round_and_return can
perform a bad computation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.gcc -std=c99 -g bug.c; valgrind --tool=memcheck ./a.out
printf("%Lg\n", strtold("42.00000000000000000001", NULL));
Actual Results: ==17999== Memcheck, a memory error detector for
==17999== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==17999== Using valgrind-2.2.0, a program supervision framework for
==17999== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==17999== For more details, rerun with: -v
==17999== Conditional jump or move depends on uninitialised value(s)
==17999== at 0x7B568F: __GI_____strtold_l_internal (in
==17999== by 0x7AF0D6: strtold (in /lib/tls/libc-2.3.3.so)
==17999== by 0x80483CA: main (bug.c:7)
Expected Results: No complaints from valgrind.
This testcase appears in stdlib/tst-strtod.c. Please consider running
valgrind on the glibc testcases. (Have someone in the EU run them, if
necessary. [I used my own memory checker, then verified that valgrind
would reproduce the complaint.])
Fedora Core 3 includes valgrind and you can run it anywhere, not just in EU.
I have ran valgrind on glibc testsuite a few months ago and fixed what I saw,
am doing it now again. Hope I won't spend too much time on false positives.
"I have ran valgrind on glibc testsuite a few months ago ..." Thank you! This
bug #141000 and bug #141137 are the ones I found this time. After the batch of
several such bugs in spring 2003 (bug #88052, etc.) I noticed that the following
major OS releases had very few, which suggested the possibility that glibc had
begun to use a memory access checker. So this strtold case was a surprise.
It seems that valgrind is a new package in FC3, and had been barred from
previous OS releases because of US patent issues (or FUD). Did these get
This should be fixed in glibc-2.3.3-87 in rawhide.