Patrick Tullmann writes: > > Yes. The string isn't walked anymore by the time it's destroyed, > > the char array could already be gone. > > Ah, okay. I'm also amazed that this hasn't cropped up before, and > still refuses to crop up with the other builds of Kaffe... Very odd. > > Anyone want to come up with a worst-case test case that generates lots > and lots of strings that all have the same hash code? > > Would a better solution to the hacks in hashtab or stringCompare be to > make the string's array of chars an explicitly allocated/deallocted > sub-object? Then the stringDestroy method could free the char array > and we'd avoid this whole race condition. Strings aren't allowed to > ever export their char-array, because that could violate their > immutability. Right? > > Do strings sometimes share underlying char arrays? That would make > the explicit alloc/dealloc scheme more difficult, too.
Yes (I think).. e.g., if created using the StringBuffer class. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
