On Thu, Jun 27, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget <gitgitgad...@gmail.com> wrote: > 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. > 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.schinde...@gmx.de>
