Personally I do not like those #ifdes for specific CRT version in header
files and in past I tried to remove them as many as possible to make
header files code more cleaner and not dependent on msvcrt vs UCRT
changes. That is why I rather suggested to "fix" the _assert function,
so also manual call to _assert function would work (which may be useful
when wrapping assert into custom function and want to propagate
line/file of the caller).
I do not think that the wchar_t[] vs char[] array size is a problem.
Assert strings are not such huge.
On Monday 08 September 2025 17:29:19 Kirill Makurin wrote:
> I did a very quick test and it seems that _O_{U8|U16|W}TEXT translation modes
> are working starting with msvcrt40.dll, so we shouldn't bother about this
> being an issue for msvcrt20.dll and older.
>
> assert.h already maps assert to _wassert when _UNICODE or UNICODE macros are
> defined. I think we could just extend this condition to include
> `__MSVCRT_VERSION__ >= 0x0800 || defined (_UCRT)`, and if we want to do it
> for msvcrt.dll, `__MSVCRT_VERSION__ == 0x0600`.
>
> The only drawback I see is that stored strings will be wchar[] instead of
> char[], resulting in larger binaries.
>
> ________________________________
> From: Pali Rohár <[email protected]>
> Sent: Tuesday, September 9, 2025 2:15 AM
> To: Kirill Makurin <[email protected]>
> Cc: mingw-w64-public <[email protected]>
> Subject: Re: Always map assert to _wassert for msvcr80.dll and later?
>
> Now I see that MS documents that _O_U8TEXT does not work together with
> printf and hence the assert does not print anything when _O_U8TEXT is
> set on stderr.
>
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
>
> Instead of redirecting the assert via #define to _wassert, I would
> rather propose to overrride _assert symbol for those affected import
> libraries and fix it to work also for _O_U8TEXT.
>
> On Monday 08 September 2025 19:03:09 Pali Rohár wrote:
> > Hello,
> >
> > This is not problem of assert, but rather of the fprintf which assert
> > calls. Same problem can be triggered by using the plain fprintf(stderr,...)
> > instead of assert(0).
> >
> > So I do not think that it makes sense to remap assert as basically all
> > functions which calls fprintf(stderr,...) are affected.
> >
> > Is not it just the _O_U8TEXT which is broken?
> >
> > On Monday 08 September 2025 15:38:09 Kirill Makurin wrote:
> > > Consider the following code:
> > >
> > > ```
> > > #include <assert.h>
> > > #include <fcntl.h>
> > > #include <io.h>
> > > #include <stdio.h>
> > >
> > > int main (void) {
> > > _setmode (_fileno (stderr), _O_U8TEXT);
> > > assert (0);
> > > return 0;
> > > }
> > > ```
> > >
> > > When compiled with MSVC, it properly prints message about failed
> > > assertion. When it is compiled with mingw-w64's headers (Msys2/UCRT64) it
> > > produces no output.
> > >
> > > mingw-w64's assert.h maps assert() macro to _wassert only when _UNICODE
> > > or UNICODE is defined. MSVC's assert.h always maps assert() macro to
> > > _wassert and even no longer exposes _assert function.
> > >
> > > How about we always map assert() macro to _wassert for msvcr80.dll and
> > > later? Since we also emulate _wassert for msvcrt.dll, it should be OK to
> > > map it to _wassert for msvcrt.dll as well.
> > >
> > > - Kirill Makurin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
