Re: [Outreachy][PATCH 2/2] Port helper/test-date.c to unit-tests/t-date.c
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 27, 2024, 06:49 UTC
- Message-ID
- <28c49738-002e-6a67-2000-cdcf1c892ab1@gmx.de>
- In-Reply-To
- <ZlbB_T8DkgmPeWQp@tanuki>
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.