This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Patch: FYI: String fixlet
- From: Tom Tromey <tromey at redhat dot com>
- To: GCC libjava patches <java-patches at gcc dot gnu dot org>
- Date: 28 Apr 2003 12:10:43 -0600
- Subject: Patch: FYI: String fixlet
- Reply-to: tromey at redhat dot com
I'm checking this in on the trunk.
This fixes a problem pointed out on the main list by Zack. The root
cause is that we weren't initializing the cachedHashCode field when
allocating a String in a certain way. I also took the opportunity to
pre-set the cachedHashCode field in the situation where we've already
computed the hash code before constructing the string.
Tom
Index: libjava/ChangeLog
from Tom Tromey <tromey at redhat dot com>
* java/lang/natString.cc (_Jv_AllocString): Initialize
cachedHashCode.
(init): Likewise.
(_Jv_NewStringUtf8Const): Likewise.
Index: libjava/java/lang/natString.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/natString.cc,v
retrieving revision 1.28
diff -u -r1.28 natString.cc
--- libjava/java/lang/natString.cc 30 Mar 2003 06:43:45 -0000 1.28
+++ libjava/java/lang/natString.cc 28 Apr 2003 16:31:42 -0000
@@ -288,6 +288,7 @@
chrs = JvGetStringChars(jstr);
memcpy (chrs, buffer, sizeof(jchar)*length);
}
+ jstr->cachedHashCode = hash;
*ptr = jstr;
SET_STRING_IS_INTERNED(jstr);
// When string is GC'd, clear the slot in the hash table.
@@ -408,6 +409,7 @@
obj->data = obj;
obj->boffset = sizeof(java::lang::String);
obj->count = len;
+ obj->cachedHashCode = 0;
return obj;
}