LIU Hao wrote: > There may be code which defines `__USE_MINGW_ANSI_STDIO` and passes `%s` for > `char*`, and there may be > code which doesn't define `__USE_MINGW_ANSI_STDIO` and passes `%S` for > `char*`. Either way is a break.
Note that with UCRT by default we use Microsoft's version with broken %s, while with the rest we use mingw-w64's stdio functions. This means that by default, for UCRT, %S/%C have Microsoft meaning, while for the rest they have POSIX meaning - code that uses %S/%C behaves differently depending on CRT. > And if `%s` is always `char*` which is ISO C and POSIX behavior, I don't see > why `%S` should be Microsoft > behavior and not POSIX. You have a good point about %S, but unlike %s, it is beyond standard C. IMO, choosing to use Microsoft's meaning for %S and %C is better, since we keep source level compatibility with MSVC. Windows is not a POSIX-conformant platform, so I would not expect presence of POSIX features which are beyond standard C, especially if they conflict with Microsoft features. This would have an interesting effect that on Windows, using %S with `wprintf` will always work to pass `char *` allowing code to behave the same with both MSVC and mingw-64 (regardless of __USE_MINGW_ANSI_STDIO). >> This code may break if someone uses tchar.h stuff, but defines >> __USE_MINGW_ANSI_STDIO. This case seems unlikely to me, since it mixes >> mingw-w64 feature __USE_MINGW_ANSI_STDIO with Microsoft feature tchar.h. >> Although, it is not impossible. Maybe our tchar.h should error out if it is >> included with __USE_MINGW_ANSI_STDIO defined to non-zero? > > This is fair enough. I misread your previous message and thought you were > asking why someone would pass > `%s` to `wprintf()`. > > Maybe such code doesn't exist in the mingw-w64 world. I would assume so. tchar.h is a Microsoft-specific stuff which portable code will not use. > I don't see a reason why someone wants to use the > Microsoft-specific `%S` to select the opposite -- if code is prepared for > Unicode then almost everything > should be UTF-16; is there a macro doing the opposite of `_T` and `TCHAR`, > which means to select the > opposite according to `UNICODE` and `_UNICODE`? I don't know. AFAIK, there is no such feature. They only use I see for Microsoft's %S is to pass `char *` to `wprintf`. >> For a long time, I have a feeling that this broken %s in Microsoft's >> versions was designed exactly to support all this tchar.h stuff. It, >> however, end up introducing an insane incompatibility on source level that >> we're facing to this day. > > Yes, but I think it's too late for such a change. This particular %s/%c issue should be pretty well-known at this point, so I agree that fixing it is too late. If users, like libstdc++, need stdio functions with standard meaning, they define __USE_MINGW_ANSI_STDIO. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
