TPA map hash calculation in case of "the Turkish-I Problem" if locale was changed.

[viewizard]

We are faced with issue, when CoreCLR calculate TPA hash for map entry with not Turkish and not Azeri locale and call TPA map lookup after locale was changed to Turkish or Azeri:

runtime/src/coreclr/src/binder/assemblybinder.cpp

Line 1066 in 97e553f

const SimpleNameToFileNameMapEntry *pTpaEntry = tpaMap->LookupPtr(simpleName.GetUnicode());

The point of issue is "the Turkish-I Problem" (https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms973919(v=msdn.10)?redirectedfrom=MSDN#the-motivation-the-turkish-i-problem). After locale changed, towupper() provide another result for i and different hash are calculated in case if file name have iletter.

All works fine (for Linux) if hash function HashiString() replaced by HashString() (case-sensitive, without towupper() call).
Is the any restrictions for HashString() usage here instead of HashiString() in case of Linux with case sensitive filesystems? Or, could we fix this in another way?

CC @alpencolt @jkotas

[ghost]

Tagging subscribers to this area: @vitek-karas
Notify danmosemsft if you want to be subscribed.

[jkotas]

Comparison of assembly names is case insensitive throughout the stack. Switching this one to case sensitive comparison would introduce a different set of inconsistencies.

Can this be fixed by using SString::HashCaseInsensitive instead of HashiString?

Ideally, the assembly binder would be written in C# where we have the well tested globalization functions available, but that's quite a bit of work.

[HJLeee]

I think both SString::HashCaseInsensitive and HashiString are using tolower series.
(In case of SELF_NO_HOST for SString::HashCaseInsensitive)

Basically, if string comparisons(or calculation for the strings) are made between a cached case insensitive one based on the initial locale and a newly converted string based on the current locale, there is a chance of malfuntion regardless of changing this to case sensitive.
If there is a background reason for comparing strings should be done case insensitive way, tolower_l and towlower_l with a cached locale could be an alternative.

[jkotas]

The SELF_NO_HOST is not used for the runtime itself. It is used only for tools.

[viewizard]

I tested SString::HashCaseInsensitive in SimpleNameToFileNameMapTraits::Hash with some simple changes like this:

        static count_t Hash(const key_t &str) { 
            SString tmp(str);
            return tmp.HashCaseInsensitive();
        }

looks like all works fine with this changes. I could see, that generated hashes not connected to locale any more (tested with us, tr and az locales), we could avoid "the Turkish-I Problem" in this way.