在 2025-12-24 09:41, Kirill Makurin 写道:
I think this depends on what degree that the Microsoft (or standard) behavior is acknowledged. This does sound like an opportunity to improve standard conformance, which should be a good thing in general.The main source of issues comes from _BLANK macro in [w]ctype.h. Microsoft header files mention that _BLANK is only used for *space* characters, so TAB must be handled explicitly. In practice, usage of _BLANK produces inconsistent results.Also note that _BLANK is used in macro versions of is[w]print, which means they may return non-zero for TAB in the same situations when is[w]ctype would. Library versions of is[w]print seem to follow behavior of is[w]ctype(_BLANK) for TAB character: 1. When iswctype(L'\t', _BLANK) is non-zero, iswprint(L'\t') is also non-zero. This is behavior of CRTs which do not have is[w]blank functions: msvcr110.dll and older. 2. When iswctype(L'\t', _BLANK) is zero, iswprint(L'\t') is also zero. This is behavior of CRTs which have is[w]blank functions: msvcr120.dll and UCRT. However, library's isprint ('\t') is always zero in "C" locale and non-zero otherwise. In addition to adding support for "blank" in wctype.c, we may want to replace is[w]ctype functions for all CRTs, which sounds like an overkill to me. I would like to know what others think about this matter and whether it is worth replacing is[w]ctype functions to properly handle TAB character.
-- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
