[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linux/Clang/Libobjc2 failure part 2 (ng)
From: |
Fred Kiefer |
Subject: |
Re: Linux/Clang/Libobjc2 failure part 2 (ng) |
Date: |
Sat, 7 Jul 2018 15:05:33 +0200 |
> Am 07.07.2018 um 13:14 schrieb David Chisnall <gnustep@theravensnest.org>:
>
> On 1 Jul 2018, at 22:39, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>
>> I finally got around to tests this and commented out most of the subclass
>> methods in GSString (apart from the length and characterAtIndex: and a few
>> that where raising an exception in an intermediate class, plus one
>> deprecated, which gets delegated from the abstract class to the concrete
>> one). Even with all these missing the test, extended with our additional
>> test code, worked correctly on my machine. Maybe you could give me an
>> additional hint where you see the unicode bugs?
>
> I found that there was some inconsistent handling of
> -rangeOfComposedCharacterSequenceAtIndex: between NSString and GSString that
> were causing failures when the NSConstantString implementation was using the
> NSString version. Looking at the code in the newabi branch of -base, where I
> was experimenting with using ICU for this, I think that’s the thing that was
> at the root of all of the test failures that I was seeing.
Yes, this was the case but on the 9th of April Richard brought these two
implementations of this method on the same level. Now we either have a bug in
both or in non of them :-)
Could we agree that now the subclassing of NSString should be correct? There
surely is room to improve the whole class cluster, but no immediate need to do
so.
Cheers,
Fred