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

[Costas Argyris]

Also, you didn't try to set the locale to .UTF-8, which is what that
page was describing.

That is because I am linking Make against MSVCRT, and that call

is only possible when linking against UCRT, AFAICT, so I didn't see

a reason to try.

CRT functions are implemented on top of Win32 APIs, and I think the
manifest affects the latter.  That's why it works.  Functionality that
is implemented completely in CRT, such as setlocale, for example, does
indeed need UCRT to work.  Or at least this is my guess.

Makes sense.    From what I have read, the manifest affects the ANSI

code page (ACP) which in turn is being used by the -A APIs (the Make

source code is calling those implicitly by not #define'ing UNICODE, i.e.

a call to CreateProcess is simply a macro that resolves to CreateProcessA

because UNICODE is not defined).

Therefore, CRT functions that are relying on those -A APIs will get to

work in UTF-8 for free it seems.

On Mon, 20 Mar 2023 at 14:05, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Costas Argyris <costas.argyris@gmail.com>
> Date: Mon, 20 Mar 2023 13:45:14 +0000
> Cc: bug-make@gnu.org, Paul Smith <psmith@gnu.org>
>
> > That's most probably because $(wildcard) calls a Win32 API that is
> > case-insensitive.  So the jury is still out on this matter, and I
> > still believe that the below is true:
>
> In that case, are you aware of any Make construct other than $(wildcard)
> that will lead to calling an API of interest?    I'd be happy to test it against
> the patched UTF-8 version of Make that I have built.

It's not easy, AFAICS in the Make sources.  Maybe it will be easier to
write a simple test program prepare a manifest for it, and see if
stricmp compares equal strings with different letter-case when
characters outside of the locale are involved.

> In any case, do you see this as a blocking issue for the UTF-8 feature?

Not a blocking issue, just something that we'd need to document, for
users to be aware of.

> Is the concern that the UTF-8 feature might break existing things that
> work, or that some things that we might naively expect to work with the
> switch to UTF-8, won't actually work?

I don't think this will break something that isn't already broken.
But it could trigger expectations that cannot be met, and so we should
document these caveats.

> > This is about UCRT specifically, so I wonder whether MSVCRT will
> > behave the same.
>
> That's true.    I wonder how the examples I did so far worked, given
> that (as you found out) my UTF-8-patched Make is linked against
> MSVCRT.    Is it just that everything I tried so far is so simple that it
> doesn't even trigger calls to sensitive functions in MSVCRT?

I think so, yes.

Also, you didn't try to set the locale to .UTF-8, which is what that
page was describing.

> Because
> from what I found online, MSVCRT does not support UTF-8, and yet
> somehow things appear to be working, at least on the surface.

CRT functions are implemented on top of Win32 APIs, and I think the
manifest affects the latter.  That's why it works.  Functionality that
is implemented completely in CRT, such as setlocale, for example, does
indeed need UCRT to work.  Or at least this is my guess.