Oh, you are right, it does sign-extend the result. I see that declarations of `btowc` and `wctob` in wchar.h do not have `_CRTIMP`.
Does it mean they just need to be removed from import libraries? It also seems my second patch is no longer needed. - Kirill Makurin ________________________________ From: LIU Hao Sent: Saturday, June 7, 2025 2:28 AM To: Kirill Makurin; mingw-w64-public Subject: Re: [Mingw-w64-public] Inconsistent behavior of btowc with "C" locale 在 2025-6-7 00:07, Kirill Makurin 写道: > I just tested return values of UCRT's wctob in "C" locale for input in range > [128,255] and it seems to do > the same thing as btowc. > > For other locales it does best-fit conversion (when it can't convert > losslessly), this why I come up with > using 20127, so we would perform best-fit conversion in "C" locale. I was > wrong. > > We could you either 28591 or range check just like in btowc. Which one would > you prefer? I think latter makes more sense; we should not do lossy conversion for the "C" locale. However I just notice that the UCRT `wbtoc()` function seems to sign-extend the result. Therefore the character `ÿ` (U+00FF) is converted to -1 which equals EOF. According to the C standard it should be zero-extended (7.29.6.1.2 The wctob function, N1570). We might want to replace this function for UCRT. bceadc54d8f32b3f14c69074892e2718eac08e3b is a good reference. -- Best regards, LIU Hao _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
