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. __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. I do not have better solution for this now. But I would think about it and maybe I come up with better idea. Also I'm not sure but I have feeling that other *_LEGACY_* are needed too, that is why I included them. But maybe this is not correct?? I do not know right now. > If we do that, we do need to be careful so we don't hit an unprefixed C++ > inline function that is used for __USE_MINGW_ANSI_STDIO=1 though. But since > 4517417c018c12de387207e51e0f3728c5164e50 most of those functions aren't > inline anyway, so I think most of those can be safe. (There are some inline > functions still, entangled with _FORTIFY_SOURCE wrappers, that I didn't take > care of that the time of that commit though.) > > Doing that requires ifdeffing the declarations of the __ms_ functions, to > only use __MINGW_ASM_CALL in the case of UCRT, but I think the total amount > of overhead that way could be less than if we add separate files for all of > this - what do you think? > > // Martin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
