From 34b80e282ea76ec793eaedaef58a36c3913dec78 Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Thu, 19 Dec 2024 19:36:15 +0200 Subject: [PATCH] Windows: Revert the setlocale(LC_ALL, ".UTF8") documentation Only leave the FindFileFirstA() notes from 20dfca81, reverting the incorrect setlocale() notes. On Windows, Gettext's overrides setlocale() with libintl_setlocale() wrapper. I hadn't noticed this, and thus my conclusions were wrong. Fixes: 20dfca8171dad4c64785ac61d5b68972c444877b --- .../w32_application.manifest.comments.txt | 21 +------------------ 1 file changed, 1 insertion(+), 20 deletions(-) diff --git a/src/common/w32_application.manifest.comments.txt b/src/common/w32_application.manifest.comments.txt index 686d0bd9..a3aea424 100644 --- a/src/common/w32_application.manifest.comments.txt +++ b/src/common/w32_application.manifest.comments.txt @@ -74,24 +74,6 @@ This is useful for programs that use main(): and thus these APIs cannot list such filenames anymore because WIN32_FIND_DATAA has a member "CHAR cFileName[MAX_PATH]". -In addition to the application manifest, setlocale(LC_ALL, ".UTF8") -needs to be called to make functions like mbrtowc() use UTF-8. Regular -setlocale(LC_ALL, "") uses a legacy code page even when an application -manifest specifies UTF-8. The effects of setlocale(LC_ALL, ".UTF8") -partially overlap with the application manifest though: - - - Application manifest affects argv[] in main() and file system APIs. - Multibyte functions like mbrtowc() aren't affected. - - - setlocale() affects file system APIs and multibyte functions like - mbrtowc(). argv[] isn't affected because argv[] has already been - constructed when an application has a chance to call setlocale(). - -To keep everything in sync, it's best to set an UTF-8 locale only when -the active code page is UTF-8 and thus argv[] is in UTF-8: - - setlocale(LC_ALL, GetACP() == CP_UTF8 ? ".UTF8" : ""); - If different programs use different code pages, compatibility issues are possible. For example, if one program produces a list of filenames and another program reads it, both programs should use @@ -101,8 +83,7 @@ char-based file system APIs. If building with a MinGW-w64 toolchain, it is strongly recommended to use UCRT instead of the old MSVCRT. For example, with the UTF-8 code page, MSVCRT doesn't convert non-ASCII characters correctly -when writing to console with printf(). With UCRT it works. Also, -MSVCRT doesn't support ".UTF8" in setlocale(). +when writing to console with printf(). With UCRT it works. Long path names