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.
I can do that. Still my concern would be: assuming that we actually learn something from this test, how would we know: 1) Which other functions besides stricmp are affected? Maybe letter-case is not the only problematic aspect. 2) Which of the above (#1) set of functions are actually called from Make source code, directly or indirectly? 3) Which of the above (#2) set of functions could be called with UTF-8 input that would cause them to break? On Mon, 20 Mar 2023 at 14:05, Eli Zaretskii <e...@gnu.org> wrote: > > From: Costas Argyris <costas.argy...@gmail.com> > > Date: Mon, 20 Mar 2023 13:45:14 +0000 > > Cc: bug-make@gnu.org, Paul Smith <psm...@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. >
