Hello the list, I am testing out a new version of the compiler / runtime that is producing NSConstantString instances with UTF-16 data. I have currently disabled a lot of the NSConstantString optimisations, on the basis of ‘make it work then make it fast’ and I’m still seeing quite a lot of test failures. The most recent ones seem to come from the fact that GSUnicodeString’s implementation of rangeOfComposedCharacterSequenceAtIndex: calls rangeOfSequence_u(), which returns a different range to NSString’s implementation.
I have ls (an GSUnicodeString) and indianLong (a UTF-16 NSConstantString) from the NSString/test00.m. If I call -getCharacters:range: on both, then I get the same set of characters for [indianLong length] characters. This is as expected. When searching for indianLong in ls, it is not found. Sticking in a lot of debugging code, I eventually tracked it down to this disagreement and when I comment out GSUnicodeString’s implementation of rangeOfComposedCharacterSequenceAtIndex: so that it uses the superclass implementation then this test passes. Please can someone who understands these bits of exciting unicode logic take a look and see if there’s any reason for the disagreement? I’m now hitting a failure in the unichar_const tests, because for some reason a GSMutableString and a (UTF-16) NSConstantString are not comparing equal, in spite of having the same hash, the same length, and the same values for both characters... David _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
