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

[Eli Zaretskii]

> 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.