Folks,
I've finally found time to track down the cause of this bug. It turns out that it is a consequence of the way that Kissme unpacks "asciz" strings with multi-byte characters. In this case Kissme is creating a String object with count == 204, offset == 0, value.length == 443, and the value array padded beyond position 203 with '\000' characters. I believe that this is a legitimate (though suboptimal) representation for the String object. If so, it is unsafe for java.lang.String to use value.length instead of count to determine length of the CharData strings; e.g. in upperCaseIndex. We could fix this (pretty easily) in Kissme, but the same problem may conceivably crop up in other VMs. -- Steve _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
