[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems
thiago.macieira at intel.com
Mon Nov 4 19:55:03 CET 2019
On Monday, 4 November 2019 10:29:16 PST André Pönitz wrote:
> All but one do not let the UI user change the environment, i.e. the
> environment is passed through the Qt UI process (so far). The one is
> Qt Creator, but even there it is not possible to configure all child
> processes, and would not be tolerable to tell users "When you create a
> new run configuration remember to undo spurious environment changes done
> by Qt".
It's highly unlikely you're running Qt Creator in a non-UTF-8 environment in
the first place. KDE has not supported such locales for 15 years.
If we were in 2004-2006 when this was recent and other Unix environments like
Solaris and HP-UXi where non-UTF-8 could be still in use I could understand
> There _are_ setups that _are_ set in stone, that are not connected
> to anything and that don't give anything on updates, or do not even
> have the possibility to be "fixed" or changed in any way.
Why are you inserting Qt 6 into them, then?
> int main()
> if (strcmp((setlocale(LC_COLLATE, "")), "C") != 0)
> Looks contrieved? [Check your hard disk before you answer.]
I'll do a full search on Clear Linux to see if there's any software that
checks the return value of setlocale().
> Potentially harmful behaviour should always be opt-in, not opt-out
> (and never be non-configurable).
I don't disagree on the statement. I just disagree on whether it's harmful.
*Not* calling qputenv could be harmful too.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development