Re: [PATCH 2/2] mingw: use Unicode functions explicitly
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Jun 27, 2019, 17:26 UTC
- Message-ID
- <CAPig+cTkzeyGjvftxmaA5Du2Dm4myzchJhrnHi=noJ7nLiLp-A@mail.gmail.com>
- In-Reply-To
- <0c9d2aead5f729942968314679c5a1ca2e0370d0.1561628237.git.gitgitgadget@gmail.com>
On Thu, Jun 27, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
Show 12 quoted lines
> Many Win32 API functions actually exist in two variants: one with > the `A` suffix that takes ANSI parameters (`char *` or `const char *`) > and one with the `W` suffix that takes Unicode parameters (`wchar_t *` > or `const wchar_t *`). > > The ANSI variant assumes that the strings are encoded according to > whatever is the current locale. This is not what Git wants to use on > Windows: we assume that `char *` variables point to strings encoded in > UTF-8. > > There is a pseudo UTF-8 locale on Windows, but it does not work > as one might expect.
What does "does not work as one might expect" mean? The reader is left hanging, not knowing why or how the UTF-8 locale on Windows is undesirable.
Show 13 quoted lines
> In addition, if we overrode the user's locale, that > would modify the behavior of programs spawned by Git (such as editors, > difftools, etc), therefore we cannot use that pseudo locale. > > Further, it is actually highly encouraged to use the Unicode versions > instead of the ANSI versions, so let's do precisely that. > > Note: when calling the Win32 API functions _without_ any suffix, it > depends whether the `UNICODE` constant is defined before the relevant > headers are #include'd. Without that constant, the ANSI variants are > used. Let's be explicit and avoid that ambiguity. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>