On Thursday 19 December 2024 14:04:10 Martin Storsjö wrote: > On Wed, 18 Dec 2024, Pali Rohár wrote: > > > On Tuesday 17 December 2024 15:29:38 Martin Storsjö wrote: > > > On Sat, 14 Dec 2024, Pali Rohár wrote: > > > > > > > Ensure that all those __ms_* printf functions calls __stdio_common_* > > > > printf > > > > functions with compatibility options, as it is required for msvcrt.dll > > > > compatibility and also because tchar.h macros depends on that old legacy > > > > behavior. > > > > > > > > For compatibility call __stdio_common_*printf function always with > > > > _CRT_INTERNAL_PRINTF_LEGACY_MSVCRT_COMPATIBILITY and > > > > _CRT_INTERNAL_PRINTF_LEGACY_THREE_DIGIT_EXPONENTS options. > > > > > > > > And for wide functions use _CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS > > > > option which ensures that %s for wide functions expects wide wchar_t* > > > > string (instead of char*). > > > > > > > > Functions (v)snprintf() and (v)snwprintf() needs additional > > > > _CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR option which ensures > > > > that > > > > return value contains number of characters required to format whole > > > > string. > > > > --- > > > > mingw-w64-crt/Makefile.am | 18 +++++++++++++-- > > > > .../__ms_fprintf.c} | 2 +- > > > > .../__ms_fwprintf.c} | 10 ++++----- > > > > mingw-w64-crt/stdio/ucrt/__ms_printf.c | 22 +++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_snprintf.c | 22 +++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_snwprintf.c | 22 +++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_sprintf.c | 22 +++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_swprintf.c | 22 +++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vfprintf.c | 17 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vfwprintf.c | 17 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vprintf.c | 16 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vsnprintf.c | 17 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vsnwprintf.c | 17 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vsprintf.c | 16 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vswprintf.c | 17 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_vwprintf.c | 16 ++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt/__ms_wprintf.c | 22 +++++++++++++++++++ > > > > > > This adds quite a lot of boilerplate code, further bloating our makefiles > > > (our Makefile.in is already 12 MB, and the step of generating Makefile > > > from > > > Makefile.in on configure can take a significant amount of time if building > > > e.g. on Windows), for something that in principle was meant to be handled > > > as > > > just one-line aliases in def files. > > > > > > I wonder if it would be possible to just do these redirections in a > > > different way? When declaring the __ms_ variants in the header, could we > > > fix > > > this by redirecting it just back to the plain unprefixed symbols with > > > asm() > > > (or __MINGW_ASM_CALL)? > > > > I think that this is not possible and it is more complicated. > > Yes, maybe... Some of these also seem to be defined as inline functions for > UCRT, so that's perhaps not ideal. > > > __ms_ variant of w- functions has to be called with > > _CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS options for tchar.h > > compatibility (usage of those macros expects that %s is _T string, which > > for unicode builds is wide-string wchar_t*). > > > > On the other hand compliant C95+ w- functions requires that %s is > > always narrow char* string. And our wprintf function is already > > compliant in both msvcrt and UCRT builds. > > > > So at least for w- printf/scanf functions we need two variants for UCRT > > builds. And this cannot be easily solved by asm alias. > > Do note that the w- functions currently default to using > _CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS, even if this conflicts with > what the C standards say about how it should behave. This is also the > default behaviour in MSVC, so for cross compatibility in code targeting > Windows, we've intentionally decided to match the MSVC behaviour rather than > hard sticking to the standard.
For msvcrt builds in C99+ mode, by default is used mingw stdio implementation and its w- functions are correct, no legacy. So switching from msvcrt builds to ucrt builds, w- functions are not correct anymore. It is correct? Should not we rather make consistent behavior? > Also, as long as the wchar stdio functions are implemented as inline (which > admittedly has some other issues), it's possible to override > _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS before including stdio.h, to pick a > different preference wrt this - this should work pretty much in the same way > as it does for MSVC. I'm not sure if we want to have those functions as inline... I think we have relevant issues with them and seems that it is better to not use inline functions... If the problem is Makefile size, I can try to look how to decrease its size. > (However with MSVC, _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS > defaults to using __local_stdio_printf_options(), and it's possible to > override this behaviour also by linking in an object file - we don't match > that aspect, yet at least.) > > // Martin We can extend code to support this. I think that this could not be hard. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
