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
