Patch: FYI: String fixlet

[Tom Tromey]

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@redhat.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;
 }