Hi Patrick,

On Wed, 29 May 2024, Patrick Steinhardt wrote:

Now the question is why we use `SetEnvironmentVariableW()` over
`_putenv_s`, and whether changing it would be safe.

The reason is that Git for Windows internally uses UTF-8 _always_. But
`_putenv_s()` knows nothing of that choice, it uses the "active code
page", which -- you guessed it -- is not at all controlled by `LC_CTYPE`
but requires its own call to a Win32 Console API function.

Now, there is theoretically that thing that you _could_ switch the active
Win32 Console to CP_UTF8, i.e. the code page that corresponds to UTF-8.
However, for that to work as well as Git for Windows' users deserve it, it
would require a recent Windows 10 version, and Git for Windows still tries
to support Windows 7 and Windows 8 [*1*].

For that reason, Git for Windows performs the conversion from UTF-8 to
UTF-16 and then uses the `*W()` Win32 API function that accepts Unicode
(no matter what the current code page is).

With that in mind, I would love to find a solution that still uses that
`*W()` Win32 API function.

Ciao,
Johannes

Footnote *1*: That support was unfortunately already partially broken when
Git LFS dropped support for Windows 7 and Windows 8, where it now fails
with a segmentation fault (or "Access Violation" in Windows speak) and
only prints a cryptic error message instead. For full details, see
https://github.com/git-for-windows/git/issues/4996. You may note that this
breakage was accepted and not reverted by the Git LFS team, citing
security concerns ;-)

So you could argue that Git for Windows is already somewhat broken for
Windows versions prior to Windows 10, but that's not because of a
carefully planned roadmap but instead due to forces that are outside my
control.