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)?
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
