LIU Hao wrote:
> 在 2026-3-18 19:29, Kirill Makurin 写道:
>>> 2. L"%S" ― second
>>> 3. L"%hs" ― third
>>
>> This is only valid with Microsoft's `wprintf`; this won't work for `char *`
>> even with meaning from Sigle Unix Specification. Microsoft's %C and %S use
>> wideness opposite to that of function called - %S for `printf` is `wchar_t
>> *` while %S for `wprintf` is `char *`.
>>
>> In Single Unix Specification, %S is always equivalent to %ls and %C is
>> always equivalent to %lc. Also, %hs is not standard nor POSIX.
>
> Yes, that's exactly the origination of my concern -- there may be code that
> passes `%s` to `swprintf()`
> for a `const char*` argument.
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.
>> I don't get it. Why would anyone ever try to use %ls to pass `char *` to
>> either `printf` or `wprintf`? Standard is clear about %ls - it is always a
>> wide character string.
>
> 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?
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.
- Kirill Makurin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
