Thank you for details. There is msvcp60.def which exports wctob and btowc, I am not sure if I should touch it.
If we don't take POSIX behavior for btowc with "C" locale for input in range [128,255], and since we replace them both for all CRTs, I think we could limit range of valid input to [0,127] to be consistent with existing implementations like glibc. Initially, the idea to allow values in range [0,255] in "C" locale was to match CRTs behavior. What do you think? I also don't like best-fit conversion, but that's how CRT does it. This also includes mb*towc* and wc*tomb* functions. - Kirill Makurin ________________________________ From: LIU Hao Sent: Saturday, June 7, 2025 6:21 PM To: Kirill Makurin; mingw-w64-public Subject: Re: [Mingw-w64-public] Inconsistent behavior of btowc with "C" locale 在 2025-6-7 02:04, Kirill Makurin 写道: > 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. If we comment them out from DEFs, then it'll be necessary to add 'misc/btowc.c' and 'misc/wctob.c' to sources of libmsvcr* and libucrt* libraries to ensure such libraries continue to provide them. This means that in 'mingw-w64-crt/Makefile.am' they should be added to `src_msvcrt_common` and `src_ucrtbase`. Individual MSVCR* libraries may have them in sources, which is no longer necessary. -- Best regards, LIU Hao _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
