Re: Linux/Clang/Libobjc2 failure part 2 (ng)

[Fred Kiefer]

> Am 24.06.2018 um 20:23 schrieb David Chisnall <gnustep@theravensnest.org>:
> 
> On 24 Jun 2018, at 17:27, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> 
>> Hi David,
>> 
>>> Am 24.06.2018 um 11:17 schrieb David Chisnall <gnustep@theravensnest.org>:
>>> 
>>> This isn’t needed with the v2 ABI, but I need help fixing the issues with 
>>> GNUstep’s NSString implementation before I can recommend enabling that for 
>>> GNUstep, because the new NSConstantString representation exposes a lot of 
>>> bugs in -base’s unicode string handling.
>> 
>> 
>> I am willing to help you with this. As far as I understand some of methods 
>> on NSString are not properly implemented based on the two primitive methods 
>> length and characterAtIndex:. Here it would help if you pointed me to the 
>> already known incomplete methods. I am not planing to use clang or your new 
>> libobjc branch so I will have to work without testing, just by code 
>> inspection.
> 
> I’ve done some things in the newabi branch that get the correct behaviour, 
> but almost certainly at the cost of performance (and I don’t have anything 
> that is particularly string-intensive to benchmark with to evaluate this) by 
> just using libicu to implement the concrete subclass and providing a few 
> wrappers.  You can test for correctness quite easily by disabling the GS 
> special cases and checking the test suite.  

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?

Fred