Am 01.08.2018 um 11:53 schrieb dick balaska:
> On 08/01/2018 05:02 AM, clipka wrote:
>> Am 01.08.2018 um 10:33 schrieb clipka:
>>
>>> @dick: Are you actively changing the C/C++ locale in qtpovray, or do you
>>> happen to know whether Qt does so by default? (buzzword `setlocale`)
>>
>> Never mind that question. According to StackOverflow, QCoreApplication
>> (on Unix/Linux) does indeed invoke
>>
>>     setlocale(LC_ALL,"")
>>
>> which screws up things. The suggested solution is to invoke
>>
>>     setlocale(LC_ALL,"C")
>>
>> right after initialization of QCoreApplication or QApplication. See here:
>>
>>
https://stackoverflow.com/questions/25661295/why-does-qcoreapplication-call-setlocalelc-all-by-default-on-unix-linux
>>
> 
> Reading that, it seems that I need to wrap POV-Ray with
> setlocale(LC_ALL,"C") and let Qt be Qt. Like, call setlocale when
> creating a session. Hmm, that will be messy; when getting a message from
> POV-Ray I would have to setlocale(LC_ALL, "") and then set it back to
> "C" after processing the message.

No, that would just risk screwing up things even more. Unfortunately,
the locale is global to the entire process, not thread-local, so you
can't just tamper with it while there's other threads running and
potentially invoking locale-dependent code.

From what I understand, Qt has its own locale mechanism, and only calls
`setlocale(LC_ALL,"")` for (a) Unix/Linux tradition and (b) to probe a
thing or two during QCoreApplication initialization; it doesn't seem to
need it to /remain/ set to that at all.

So once QApplication or QCoreApplication has been initialized, it should
be safe to just invoke `setlocale(LC_ALL,"C")` once and never touch the
C/C++ locale again afterwards.


There's a potential workaround for GNU/Linux machines in invoking
`uselocale()` during thread initialization, which sets the locale for
the individual thread only. However, this function is not part of the
C/C++ standard.

Post a reply to this message