On Sunday 21 June 2026 12:08:26 Kirill Makurin wrote: > Pali Rohár <[email protected]> wrote: > > > On Sunday 21 June 2026 06:13:42 Kirill Makurin wrote: > >> Pali Rohár <[email protected]> wrote: > >> > - _set_error_mode is not available in crtdll.dll, msvcrt10.dll and > >> > msvcrt20.dll CRT libs; but this is not a problem, I can provide > >> > working "emulation" of this function which would return correct value > >> > for _set_error_mode (_REPORT_ERRMODE) call. This is because these > >> > libraries always prints message to stderr via fprintf; not to GUI. > >> > >> I wanted to suggest prividing emulation for `_set_error_mode ` as a > >> follow-up, so we could query current setting from `_wassert` emulation and > >> choose correct code page for conversion. > > > > Ok. > > There is one more thing to keep in mind. When CRT locale is set to "C", > `___lc_codepage_func` returns zero, which when passed to > `WideCharToMultiByte`, act as if we used CP_ACP. This not really correct. > > CRT conversion functions in "C" locale act as if it was ISO-8859-1, but they > do simply range checking instead of calling Windows APIs internally. Code > page for ISO-8859-1, 28591, cannot be used here because it may not be > installed on XP and older.
OMG. Also this step is going to be more complicated. Is "C" locale in CRT libs allowing full ISO-8859-1 8-bit range? Or just 7-bit ASCII subset range? Maybe it would be better to use CRT functions (e.g. wcrtomb() in loop) for converting to CRT locale? And WideCharToMultiByte for converting to CP_ACP for GUI output? Anyway, conversion from UTF-16 (wchar_t) to 7-bit ASCII or 8-bit ISO-8859-1 is trivial because ISO-8859-1 direct extension from 7-bit ASCII and UNICODE is direct extension from ISO-8859-1 (first 256 UNICODE code points matches ISO-8859-1). So this conversion can be written in simple loop. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
