Closed Dragorn421 closed 2 weeks ago
As I understand it, forcing the C locale prevents UTF-8 support. I don't know offhand if ares or nall try to do anything in a case-insensitive way, or count the number of code-points (as opposed to bytes) in a string or whatever, but that might be regressed without at least the C.UTF-8
locale, if not the user's actual configured locale.
Yeah I am quite reluctant to change the entire locale and not just the numeric. It’s a shame this isn’t thread safe or the original solution would be fine.
Changed to only set LC_NUMERIC
to C, after gtk/qt init
Testing with gtk, still good
Fixes #1526
The default locale in a C program is the "C" locale ( POSIX https://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html , C89 standard ), which we want for string-number formatting and parsing
gtk ( https://gitlab.gnome.org/GNOME/gtk/-/blob/a274a5ff4b2a2f9cf9731cdddbb456a0758fcbcc/gtk/gtkmain.c#L435 ) and Qt ( 5 https://codebrowser.dev/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#597 , 6 https://codebrowser.dev/qt6/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#613 ) set the locale from the environment variables instead. (by passing "" as the locale, cf
setlocale
)This PR sets the locale for
LC_NUMERIC
back to "C" withsetlocale
after initializing gtk/QtI tested this with gtk, saw no problem in the GUI with a rom named
/home/dragorn421/Desktop/c'est la fête/rom de noël __ やあ!.z64
Qt codepath is not tested