Re: Incorrect information about setlocale behavior on native windows
Kirill Makurin <[email protected]>
| Newsgroups | gmane.comp.lib.gnulib.bugs |
|---|---|
| Message-ID | <Ty-eIF4xsfyus_nGcSBTnEBYk-aiT3dkrnjrwd2Z4hVls_F4qZjymJWgJo5y2dTgQWgXsyvmF9FwiGT2WTU_lozP3Lq3sOcnsU5JjvXi0kQ=@proton.me> |
On Friday, August 21st, 2026 at 4:48 PM, Paul Eggert <[email protected]> wrote: > On 2026-08-21 01:14, Kirill Makurin wrote: > > I believe that original impression of setting LC_CTYPE to "C" comes from "C" being the active locale before problematic `setlocale` call. > Are you suggesting something like the attached patch to Gnulib? If not, what would be a better patch? My main thought was to point out that behavior documented by gnulib is incorrect, so it can be corrected. > Is it possible that sometimes setlocale leaves LC_CTYPE alone, and sometimes sets it to "C"? If so, the attached code patch would handle either case, but the documentation patch would need changing. The behavior of preserving LC_CTYPE category seems to be consistent for all C Runtime Libraries (CRTs) on Windows (from crtdll.dll to UCRT). The only CRTs I did not test are msvcr80.dll and msvcr90.dll; they require proper application manifest to work and I do not want to deal with it. This behavior triggers when code page passed to `setlocale` is supported by Windows, but not CRT. If you pass some random number which is not a valid code page, `setlocale` always fails. > I have not installed the attached patch, as I don't use MS-Windows and can't easily test it, and it's not obviously OK. - Kirill Makurin