Re: [Mingw-w64-public] [PATCH] crt: Replace wprintf() by __ms_wprintf() call and use %ls for wchar_t* types
On Sat, 14 Dec 2024, Pali Rohár wrote:
On Tuesday 03 December 2024 16:31:16 Martin Storsjö wrote:
On Wed, 27 Nov 2024, Pali Rohár wrote:
This ensures that mingwex wprintf implementation will not be used and
statically linked when not needed. And also make it more predictable as %ls
format is always using wide string.
But the mingwex implementation shouldn't really be used here anyway? All of
mingw-w64-crt is compiled with -D__USE_MINGW_ANSI_STDIO=0?
So this shouldn't have any functional effect, it only makes things clearer -
or do I misunderstand something here?
---
mingw-w64-crt/crt/crtexe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index cdf5dcd25894..2c6fbd7e7062 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -89,8 +89,8 @@ __mingw_invalidParameterHandler (const wchar_t *
__UNUSED_PARAM_1(expression),
uintptr_t __UNUSED_PARAM(pReserved))
{
#ifdef __MINGW_SHOW_INVALID_PARAMETER_EXCEPTION
- wprintf(L"Invalid parameter detected in function %s. File: %s Line: %d\n",
function, file, line);
- wprintf(L"Expression: %s\n", expression);
+ __ms_wprintf(L"Invalid parameter detected in function %ls. File: %ls Line:
%d\n", function, file, line);
+ __ms_wprintf(L"Expression: %ls\n", expression);
#endif
}
Both before and after this change, I get errors due to calling an undefined
function, if I compile this file with
-D__MINGW_SHOW_INVALID_PARAMETER_EXCEPTION - so I'd like to have that fixed
too before I'd be willing to take on this change.
// Martin
Should be fixed by changes which I sent to the list, which defines all
__ms_* stdio functions for UCRT builds.
It makes no difference - these files in mingw-w64-crt are built with with
a fixed __MSVCRT_VERSION__, independent of the default mode in the
headers.
Please test compiling this file yourself with
-D__MINGW_SHOW_INVALID_PARAMETER_EXCEPTION; before this change, it errors
out with
../crt/crtexe.c:90:3: error: call to undeclared function 'wprintf'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
90 | wprintf(L"Invalid parameter detected in function %s. File: %s
Line: %d\n", function, file, line);
| ^
and with this change:
../crt/crtexe.c:90:3: error: call to undeclared function '__ms_wprintf';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
90 | __ms_wprintf(L"Invalid parameter detected in function %ls. File:
%ls Line: %d\n", function, file, line);
| ^
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/3] crt: Define symbols for all __ms_* printf functions for UCRT builds
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
Re: [Mingw-w64-public] [PATCH 2/3] crt: Define symbols for all __ms_* printf functions for UCRT builds
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
Re: [Mingw-w64-public] [PATCH] crt: Replace wprintf() by __ms_wprintf() call and use %ls for wchar_t* types
On Tuesday 17 December 2024 15:34:40 Martin Storsjö wrote:
> On Sat, 14 Dec 2024, Pali Rohár wrote:
>
> > On Tuesday 03 December 2024 16:31:16 Martin Storsjö wrote:
> > > On Wed, 27 Nov 2024, Pali Rohár wrote:
> > >
> > > > This ensures that mingwex wprintf implementation will not be used and
> > > > statically linked when not needed. And also make it more predictable as
> > > > %ls
> > > > format is always using wide string.
> > >
> > > But the mingwex implementation shouldn't really be used here anyway? All
> > > of
> > > mingw-w64-crt is compiled with -D__USE_MINGW_ANSI_STDIO=0?
> > >
> > > So this shouldn't have any functional effect, it only makes things
> > > clearer -
> > > or do I misunderstand something here?
> > >
> > > > ---
> > > > mingw-w64-crt/crt/crtexe.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
> > > > index cdf5dcd25894..2c6fbd7e7062 100644
> > > > --- a/mingw-w64-crt/crt/crtexe.c
> > > > +++ b/mingw-w64-crt/crt/crtexe.c
> > > > @@ -89,8 +89,8 @@ __mingw_invalidParameterHandler (const wchar_t *
> > > > __UNUSED_PARAM_1(expression),
> > > > uintptr_t __UNUSED_PARAM(pReserved))
> > > > {
> > > > #ifdef __MINGW_SHOW_INVALID_PARAMETER_EXCEPTION
> > > > - wprintf(L"Invalid parameter detected in function %s. File: %s Line:
> > > > %d\n", function, file, line);
> > > > - wprintf(L"Expression: %s\n", expression);
> > > > + __ms_wprintf(L"Invalid parameter detected in function %ls. File: %ls
> > > > Line: %d\n", function, file, line);
> > > > + __ms_wprintf(L"Expression: %ls\n", expression);
> > > > #endif
> > > > }
> > >
> > > Both before and after this change, I get errors due to calling an
> > > undefined
> > > function, if I compile this file with
> > > -D__MINGW_SHOW_INVALID_PARAMETER_EXCEPTION - so I'd like to have that
> > > fixed
> > > too before I'd be willing to take on this change.
> > >
> > > // Martin
> >
> > Should be fixed by changes which I sent to the list, which defines all
> > __ms_* stdio functions for UCRT builds.
>
> It makes no difference - these files in mingw-w64-crt are built with with a
> fixed __MSVCRT_VERSION__, independent of the default mode in the headers.
>
> Please test compiling this file yourself with
> -D__MINGW_SHOW_INVALID_PARAMETER_EXCEPTION; before this change, it errors
> out with
>
> ../crt/crtexe.c:90:3: error: call to undeclared function 'wprintf'; ISO C99
> and later do not support implicit function declarations
> [-Wimplicit-function-declaration]
>90 | wprintf(L"Invalid parameter detected in function %s. File: %s
> Line: %d\n", function, file, line);
> | ^
>
> and with this change:
>
>
> ../crt/crtexe.c:90:3: error: call to undeclared function '__ms_wprintf'; ISO
> C99 and later do not support implicit function declarations
> [-Wimplicit-function-declaration]
>90 | __ms_wprintf(L"Invalid parameter detected in function %ls. File:
> %ls Line: %d\n", function, file, line);
> | ^
>
> // Martin
Ou, I see. I must have done something totally wrong and so that during
my test the -D__MINGW_SHOW_INVALID_PARAMETER_EXCEPTION was not
propagated at all and the code was wrongly compiled and I thought that
everything is OK.
For next test, I have to check objdump -d output.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 3/3] headers: Use register variable for NtCurrentTeb implementation on aarch64.
On 16.12.2024 08:13, LIU Hao wrote: 在 2024-12-13 19:08, Jacek Caban 写道: This change is based on Wine's winnt.h implementation. Using a register variable for NtCurrentTeb allows the compiler to optimize the access more effectively. --- mingw-w64-headers/include/winnt.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) These 3 patches all look good to me. Thanks. Thanks for reviews. I rechecked, slightly improved white spaces in the first patch and pushed. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
