Incorrect behavior of string.IndexOf in different cultures

[rolfbjarne]

From @JeroenBer on Sun, 12 Jan 2025 12:34:19 GMT

Apple platform

iOS

Framework version

net9.0-*

Affected platform version

Dotnet version 9.0.101, ios workload 18.2.9170/9.0.100, MacBook Intel Sequoia 15.2, XCode 16.2, iPhone 15 / 16 emulator

Description

After upgrading from .NET8 to .NET9 our app crashed on Exceptions. After troubleshooting the cause is:

String.IndexOf() returns incorrect values.

// Should always return i = -1
var x = "";
var i = x.IndexOf(" ")

// Since it cannot find a space in an empty string it should return -1

The above scenario should return -1 on all cultures. On iOS it returns 0 after setting cultures. This leads to problems later since the code thinks the string is found at position 0.

On .NET8 and other platform it always returns -1. Also after setting the culture. So it seems introduced with .NET 9.

Steps to Reproduce

1. Download the repro app: https://github.com/JeroenBer/net9-culture-issues
2. install .net9 ios workload
3. run the app on the iOS simulator
4. it will show the IndexOf returns 0 instead of -1.

Did you find any workaround?

There is NO good workaround. Since it cannot be guaranteed that this behavior leeds to issues in External libraries using this trivial function.
For code in own control IndexOf stringcomparison type Ordinal can solve it.

It has something to do with the culture. Please let me know if it's reproducable ? And what the cause is ?

Are there any other culture thing going wrong on .NET 9 due to the same cause ?

I think this is a very serious bug and should be solved as soon as possible in .NET 9 iOS.

Relevant log output

No response

Copied from original issue dotnet/macios#21947

[rolfbjarne]

From @JeroenBer on Sun, 12 Jan 2025 12:59:22 GMT

In fact if the string is "", it doesn't matter what you search, it will always return 0, instead of -1 when using cultures on iOS

NOTE: The other way around it should return 0 but not this way!

[rolfbjarne]

From @rolfbjarne on Mon, 13 Jan 2025 09:25:58 GMT

I can reproduce this with the provided sample, and it looks like a runtime issue, so moving to dotnet/runtime.

[vitek-karas]

/cc @matouskozak

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[JeroenBer]

@vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger @matouskozak

Can this please be fixed in the 9.0 version ? This is currently holding us back from migrating to .NET 9.0. In my opinion this is a very serious issue. It can cause all sorts of nasty problems and side effects that are very hard to discover. Also scanning/updating your own code is not enough, the bug could still appear from any external library that is being used, but that's impossible to check and hard to fix.
Also what is the root cause of this, might there be more that's going wrong now on ios with .NET 9.0 ?

[matouskozak]

@vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger @matouskozak

Can this please be fixed in the 9.0 version ? This is currently holding us back from migrating to .NET 9.0. In my opinion this is a very serious issue. It can cause all sorts of nasty problems and side effects that are very hard to discover. Also scanning/updating your own code is not enough, the bug could still appear from any external library that is being used, but that's impossible to check and hard to fix. Also what is the root cause of this, might there be more that's going wrong now on ios with .NET 9.0 ?

Hello @JeroenBer, yes, I'm working on getting the fix merged and backported to .NET 9. The root cause was a bug in the code responsible for retrieving globalization information via Objective-C APIs and that we didn't test this code path properly. We are continuing to audit the code to find other possible issues. You can check the dotnet/runtime issues for other iOS globalization-related bugs.