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.
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.
My original idea was to define everything in separate .c files, not via
aliases in header files.
This could also solve above problem and for example problems with
non-standard _vsnprintf or _vsnwprintf functions (which should never use
_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR and always use
_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION).
Those extra flags for the specific functions that want specific behaviours
regarding null termination and other details is not a problem; we already
add those extra flags as necessary in the right functions - I don't see
what problem there is to solve about that?
But you said that this is not maintainable and I have not come up with a
better idea.
Yes, your suggestion would create duplicate copies of all these stdio
functions, for all the __ms_ function names. We don't want that.
It feels like you're suggesting extra complexity just to fulfill the
corner case correctness that only you are requesting, that nobody else
wants.
One suggestion:
What about moving all ucrt stdio functions into own subdirectory?
E.g. mingw-w64-crt/stdio/ucrt/ So we do not need to prefix every file
with ucrt_. It would be quite confusing how we should call a file which
contains UCRT's _vsnprintf function and file with UCRT vsnprintf function.
I don't mind creating a subdirectory for the UCRT files - but I don't see
how that changes anything. Even with a separate subdirectory, I don't want
another 30+ extra copies of all the stdio functions. Nobody else wants
that.
FWIW, if we don't have a good path forward about this, we should revert
581532b8e49a0e10cbdfe2332a8c1d61ff3d6820 and stop referencing symbols that
don't exist.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
