在 2026-3-18 20:36, Kirill Makurin 写道:
But this patch series does not touch meaning for %s and %c, right? It only changes meaning of non-standard %S and %C to be consistent with that of Microsoft's versions. If users want to ensure standard meaning for %s and %c, they have to use __USE_MINGW_ANSI_STDIO.If you meant %S in the last sentence, then should be no break, because this is Microsoft behavior, which this patch series provides for all CRTs.
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.
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.
It may be a result of macro expansion like this: LPCTSTR name = ...; int index = ...; TCHAR key[64]; _stprintf(key, _T("%s%d"), name, index);This code, when used with Microsoft's stdio functions, will work just fine. Microsoft's %s is `char *` for `printf` and `wchar_t *` for `wprintf`. 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 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.
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. -- 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
