bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setlocale() issue on Windows with UTF-8


From: Lasse Collin
Subject: Re: setlocale() issue on Windows with UTF-8
Date: Wed, 25 Dec 2024 21:25:47 +0200

On 2024-12-24 Bruno Haible wrote:
> I hope it works fine in your environment as well.

I haven't learned yet how to produce a distribution tarball from
gettext.git but I didn't try for many minutes either. I ran autogen.sh
successfully etc. but, for some some reason I don't understand, "make
dist" wants to build the package first and then it fails because I
didn't install ppcx64.

Instead, I started with 0.22.5 tarball (I know, not the latest
release). I copied newer Gnulib files to intl/gnulib-lib and newer
Gettext setlocale.c to to intl. And indeed, it seems to work now. :-)

> The output of your test program, when no LC_* nor LANG environment
> variable is set, has changed:
> 
> * Linked with legacy.o, the output was
> -------------------------------------------------
> LC_ALL: C
> GetACP: 1252 (legacy)
> mbrtowc: 1 (legacy)
> utf8str: äößš567 (garbled but it's *not* a bug)
[...]
> * Linked with utf8.o, the output was
> -------------------------------------------------
> LC_ALL: C
> GetACP: 65001 (UTF-8)
> mbrtowc: 1 (legacy)
> utf8str: äößš567

This might not matter but I mention it just in case. Your sample
outputs *before* the fix were different than I expected:

  - I got "fi_FI" with unmodified gettext 0.22.5 when not in UTF-8
    mode. "en_US" would be fine too. I don't understand how the old
    gettext could produce "C" on native Windows.

  - The utf8str isn't garbled in the legacy.o case above but it should
    be. Before the recent Gnulib fixes, the utf8str should be garbled
    in the utf8.o case too.

I can reproduce your results if I build under the MSYS environment
instead of UCRT64. (MSYS environment is about the same as Cygwin. It's
not native Windows.)

    - MSYS gcc   = /usr/bin/gcc
    - UCRT64 gcc = /ucrt64/bin/gcc

Your outputs after the fix look what I expected.

Thanks for the quick fix!

-- 
Lasse Collin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]