LIU Hao wrote:
> If there's still disagreement about this change, it doesn't look like a clear
> signal for it to be checked in.
Both me and Pali expressed different opinions on this; you can read our
discussion in original "Update assert() implementation" thread. So, another's
opinion would be welcome here.
I think that having `_assert` wrapper which simply changes translation mode on
`stderr` to `_O_TEXT` before calling CRT's `_assert` is overkill and
unnecessary, especially since we do it for all CRTs. This makes sense only for
crtdll.dll and msvcrt{20,40}.dll, which may be redirected to OS msvcrt.dll (see
previous discussion for details).
We already provide `_wassert` emulation for all pre-msvcr80.dll CRTs, so why we
cannot do such translation mode switch (which I really don't like, even if done
conditionally) within `_wassert` before calling `_assert`?
> Because Microsoft CRT calls `_wassert()`, this looks like a correct direction
> to move. By default GCC
> assumes source files are in UTF-8 which has an effect on the encoding of
> `__FILE__`, so non-ASCII paths
> in messages might become gibberish.
I also made point that `_[w]assert` functions should be considered internal CRT
functions; Microsoft documentation explicitly advices against calling them
directly. More, recent Microsoft headers do not expose `_assert` at all, which
will break any project which references it.
I was the one who brought issue with assert() not producing output when
`stderr` is set to a Unicode translation mode. For me, issue got resolved when
I updated some of tests, and they started including project-specific config.h
which always defines _UNICODE, which in turn make assert() use `_wassert`.
Always using `_wassert` solves this issue, except corner cases when crtdll.dll
and msvcrt{20,40}.dll are redirected to OS msvcrt.dll.
- Kirill Makurin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
