This is the mail archive of the
mailing list for the Java project.
Re: Patch: FYI: important memory-trashing fix
>>>>> "Scott" == Scott Gilbertson <firstname.lastname@example.org> writes:
Scott> Double.parseDouble no longer parses strings with leading
Scott> spaces. My app previously worked but now gets a
Scott> NumberFormatException. A small test case (attached) sees the
Scott> same thing.
Scott> It seems to me that "length + start" is guaranteed to be no greater than
Scott> "str->length()", so the old version was correct.
You are right. Sorry about that, and thanks for catching this.
Fixed as appended.
There's already a Mauve test for this. I'm not sure why my nightly
testing didn't pick up this failure, since running Mauve by hand
showed it :-(
from Tom Tromey <email@example.com>
* java/lang/natDouble.cc (parseDouble): Reverted patch of
RCS file: /cvs/gcc/gcc/libjava/java/lang/natDouble.cc,v
retrieving revision 1.17
diff -u -r1.17 natDouble.cc
--- java/lang/natDouble.cc 14 Nov 2003 01:48:30 -0000 1.17
+++ java/lang/natDouble.cc 26 Nov 2003 17:29:48 -0000
@@ -183,7 +183,7 @@
// Note that UTF can expand 3x.
char *data = (char *) __builtin_alloca (3 * length + 1);
- jsize blength = _Jv_GetStringUTFRegion (str, start, str->length(), data);
+ jsize blength = _Jv_GetStringUTFRegion (str, start, length, data);
data[blength] = 0;
struct _Jv_reent reent;