On Thu, 20 Mar 2025, Pali Rohár wrote:
On Thursday 20 March 2025 21:57:42 Martin Storsjö wrote:
On Thu, 20 Mar 2025, Pali Rohár wrote:
For example in -std=c99 mode we should rather follow C99 standard and
hence %s in wprintf should take char*.
So far, we have decided to match MSVC in this aspect.
For MSVC 2015 CTP1 they first announced that they would change MSVC to
default to the C99 compatible mode, but after overwhelming response from
their users, they reverted this decision, so it defaults to the old legacy
mode.
Yes, I'm aware that this is inconsistent with when __USE_MINGW_ANSI_STDIO=1
is defined (as it is done for msvcrt.dll when building with -stdc=c99, but
not for UCRT), as that uses the C99 compatible mode.
But I have not heard any reports about this inconsistency - which can mean
one out of:
- the status quo is correct
- very few codebases use wchar_t
- msys2 hardcodes __USE_MINGW_ANSI_STDIO=1 when building most of their
packages anyway, so much fewer are exposed to this default case
Overall, very few portable codebases use wchar_t anywhere else other than
for windows specific codepaths. Therefore, I think it makes more sense to
match MSVC, than to try to match the C99 standard in this aspect, if nobody
else is using wchar_t in the C99 standard way.
But anyway, this whole discussion is mostly beside the point here. We have a
current default behaviour - this patchset is not changing that. Whether we
should change that default is a different discussion.
Ok, so move forward. If this is not changing the behavior, we can
discuss later as you wrote.
But __ms_wprintf should take wchar_t* (independently of -std= option) as
this is on what tchar.h depends.
I really think that is overkill and not necessary. If calling __ms_wprintf,
I would expect to get the same as if I would be calling wprintf() with
__USE_MINGW_ANSI_STDIO=0 - whichever default or customized behaviour that
is.
I thought that the intent is opposite. __ms_wprintf() would always provide
MS behavior (independently of -std= option) and wprintf() would provide
the behavior according to -std= option.
I guess this is the main question.
What wprintf() should do is IMO more complex/nuanced than just following
-std=; for codebases initially developed with MSVC, it's more relevant to
match MSVC's defaults - and MSVC's ways of customizing it (and the first
part of this patchset adds that kind of customizability).
Secondly, nobody in user code is calling __ms_wprintf directly. So this is
mainly about what's supposed to happen when calling e.g. _tprintf. And I
think that's also the least surprising if that simply does the same as
calling either regular printf() or wprintf().
And with that in mind, I'm actually wondering if we should revert
581532b8e49a0e10cbdfe2332a8c1d61ff3d6820 regardless of this patchset? I'm
actually less convinced that we want to have this distinction. If we have
printf() and wprintf() with __USE_MINGW_ANSI_STDIO=1 semantics, then it
can also be seen quite confusing if _tprintf() behaves differently.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
