root
/
xz
mirror of https://git.tukaani.org/xz.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Windows: Revert the setlocale(LC_ALL, ".UTF8") documentation 

Only leave the FindFileFirstA() notes from 20dfca81, reverting
the incorrect setlocale() notes. On Windows, Gettext's <libintl.h>
overrides setlocale() with libintl_setlocale() wrapper. I hadn't
noticed this, and thus my conclusions were wrong.

Fixes: 20dfca8171
(cherry picked from commit e607329a615759f1519016595dd38df7c89208f2)
This commit is contained in:
Lasse Collin 2024-12-19 19:36:15 +02:00
parent 4e0ebbabe4
commit 3ed40b9f87
No known key found for this signature in database
GPG Key ID: 38EE757D69184620
1 changed files with 1 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
src/common/w32_application.manifest.comments.txt
View File

@ -74,24 +74,6 @@ This is useful for programs that use main():
and thus these APIs cannot list such filenames anymore because and thus these APIs cannot list such filenames anymore because
WIN32_FIND_DATAA has a member "CHAR cFileName[MAX_PATH]". 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 If different programs use different code pages, compatibility issues
are possible. For example, if one program produces a list of are possible. For example, if one program produces a list of
filenames and another program reads it, both programs should use 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 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 to use UCRT instead of the old MSVCRT. For example, with the UTF-8
code page, MSVCRT doesn't convert non-ASCII characters correctly code page, MSVCRT doesn't convert non-ASCII characters correctly
when writing to console with printf(). With UCRT it works. Also, when writing to console with printf(). With UCRT it works.
MSVCRT doesn't support ".UTF8" in setlocale().
Long path names Long path names