LIU Hao wrote:
> One thing that you should be aware of is that libstdc++ defines 
> `__USE_MINGW_ANSI_STDIO` unconditionally
> [1]. This means that mostly all existent C++ code has been calling mingw-w64 
> *printf functions since 15
> years ago, and C++ is far more widely used than C.
>
>
> In order to evaluate such a change, we need some statistics about what 
> existing code passes to
> `wprintf()` for `const char*`, such as [2] from GitHub Copilot:
>
>     Approximate ranking from this sample
>     From the returned examples I could inspect, the observed ordering is 
> roughly:
>
>     1. L"%s" — most common

This is the standard way to pass `char *` argument to both `printf` and 
`wprintf`, this is what all applications should do.

The problems start when applications call Microsoft's `wprintf` with %s, where 
it stands for `wchar_t *` instead of `char *`. This is what makes applications 
to use non-standard %hs or %S in the first place, so they can pass `char *` to 
Microsoft's `wprintf`.

>    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.

>     4. L"%ls" for const char* — effectively absent in this sample
>
> ... which does not look like an affirmative response.

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.

> [1]:
> https://github.com/gcc-mirror/gcc/blob/7d70ce4e9a0244a2585a4bf1a9205bfb0443cc2e/libstdc%2B%2B-v3/config/os/mingw32-w64/os_defines.h#L47-L51
> [2]: https://github.com/copilot/c/8bbea74e-1494-4c46-94c5-84b80f2e0323

- Kirill Makurin

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to