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

[Dmitry Shachnev]

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?

--
Dmitry Shachnev