Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

AFAIK, GetACP can never return UTF-8, except if the program was
compiled with those resources.

In the scenario I am describing, Make was compiled with the resource,

so GetACP should return UTF-8 on the one hand.    On the other hand

though, since Make is running in Windows version < 1903, it shouldn't

return UTF-8 because this functionality is not supported in that version.

But yes, I will make sure to check this in practice.

On Tue, 11 Apr 2023 at 14:46, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Costas Argyris <costas.argyris@gmail.com>
> Date: Tue, 11 Apr 2023 14:42:30 +0100
> Cc: bug-make@gnu.org, Paul Smith <psmith@gnu.org>
>
>> I don't think this is needed: if GetACP returns the UTF-8 codepage, it
>> must be that UTF-8 is supported.  I'm not aware of any way of
>> affecting GetACP other than by a manifest such as this one (or perhaps
>> making UTF-8 a system-wide default, which is fine by us).
>
> This is the scenario I am concerned about:
>
> Assume Make was built with UTF-8 support, and downloaded by a
> user running Windows < 1903.    I am not sure what GetACP would
> return in this case - If it returns the legacy code page, despite the
> fact that the UTF-8 manifest is embedded in Make, then we are good.
> But if GetACP returns UTF-8, because of the manifest that was
> embedded at build time, this will be confusing because --version will
> say UTF-8 but Make will actually work in the legacy encoding because
> of the < 1903 Windows version.

AFAIK, GetACP can never return UTF-8, except if the program was
compiled with those resources.

> I haven't tested this though, so it might not even be a real issue, just
> noting it down to check it later when I have the implementation.

Yes, verifying this would be good, thanks.