JIT: Switch config values to UTF8

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

https://docs.microsoft.com/dotnet/core/

MIT License

15.25k stars 4.73k forks source link

JIT: Switch config values to UTF8 #109418

Open jakobbotsch opened 1 day ago

jakobbotsch commented 1 day ago

Switch JitConfig strings from UTF16 to UTF8
Switch relevant JIT-EE and host methods to UTF8
Remove getJitTimeLogFilename JIT-EE call, which seemingly existed to avoid having a config parser in the JIT in release builds, but that ship has sailed

Subsumes #104805

dotnet-policy-service[bot] commented 1 day ago

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch See info in area-owners.md if you want to be subscribed.

jakobbotsch commented 1 day ago

Hmm, this seems to break the ability to specify file paths with unicode characters on Windows. Probably can't switch to fopen.

jakobbotsch commented 22 hours ago

Hmm, this seems to break the ability to specify file paths with unicode characters on Windows. Probably can't switch to fopen.

Actually it works fine with UTF8 enabled, this was operator error.

jakobbotsch commented 22 hours ago

PTAL @dotnet/jit-contrib @AaronRobinsonMSFT

jkotas commented 17 hours ago

Actually it works fine with UTF8 enabled, this was operator error.

Do you mean that you have to have your Windows configured to CP_ACP == CP_UTF8?.

jakobbotsch commented 16 hours ago

Actually it works fine with UTF8 enabled, this was operator error.

Do you mean that you have to have your Windows configured to CP_ACP == CP_UTF8?.

I think so, but I haven't confirmed. I can try to confirm whether this is the case. Do you think we should continue using _wfopen for Windows to avoid this regression? I thought it might be ok since most of the JIT env vars involving file paths are pretty obscure / power user scenarios.

jkotas commented 11 hours ago

I thought it might be ok since most of the JIT env vars involving file paths are pretty obscure / power user scenarios.

I think it is ok for debug-only configs. If it is used for documented env vars in release builds, it is a compliance issue. All features have to handle globalization properly, even the obscure ones.