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.
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. (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
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
