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
