Different QLocale.decimalPoint values, little-endian (amd64, arm64, etc) vs. big-endian (s390x)

[Phil Thompson]

On 23/05/2025 13:38, Dmitry Shachnev wrote:
> Hi Phil!
> 
> On Fri, May 23, 2025 at 11:51:53AM +0100, Phil Thompson wrote:
>> In fact it may be more likely that it's the arguments to the QLocale 
>> ctor
>> that are the problem. So the outputs of...
>> 
>> print(QLocale.Language.Dutch.value)
>> print(QLocale.Script.LatinScript.value)
>> print(QLocale.Country.Netherlands.value)
>> 
>> ...would also be interesting.
> 
> They are the same on both systems, and match the definition in 
> qlocale.h:
> 
>     >>> print(QLocale.Language.Dutch.value)
>     72
>     >>> print(QLocale.Script.LatinScript.value)
>     66
>     >>> print(QLocale.Country.Netherlands.value)
>     165
> 
> On Fri, May 23, 2025 at 11:40:52AM +0100, Phil Thompson wrote:
>> What about other QLocale calls that return a QString (eg.
>> nativeLanguageName())?
> 
> This is much more interesting. On amd64:
> 
>     >>> l = QLocale(QLocale.Language.Dutch)
>     >>> l.language()
>     <Language.Dutch: 72>
>     >>> l.name()
>     'nl_NL'
>     >>> l.nativeLanguageName()
>     'Nederlands'
> 
> On s390x:
> 
>     >>> l = QLocale(QLocale.Language.Dutch)
>     >>> l.language()
>     <Language.English: 75>
>     >>> l.name()
>     'en_US'
>     >>> l.nativeLanguageName()
>     'American English'
> 
> And I think I have a hypothesis. Qt defines the enums as ushort since 
> Qt 6:
> https://code.qt.io/cgit/qt/qtbase.git/commit?id=8b0e068847c03c58f510f89c85dcc7a5e4ac7ef4
> 
> However qlocale.sip does not do that. And if we pass a 4-bytes int, on 
> big
> endian systems the code will read from the first two bytes which are 
> zeroes,
> and that gets interpreted as AnyLanguage.
> 
> Can I add ": ushort" to qlocale.sip to give it a try, or the syntax is
> different?

It isn't supported - it is assumed all enums are ints. I need to think 
about how best to support this.

Phil