LIU Hao

> MINGW64: > > ``` > /mingw64/bin/gcc > ``` > > I am using gcc with UCRT64. Native language support (NLS) is not enabled for UCRT64 GCC: > **lh_mouse@lhmouse-pc ~...

See also: https://github.com/niXman/mingw-builds/issues/666

> is [#24750](https://github.com/msys2/MINGW-packages/pull/24750) PR related to this issue? Maybe, if we want to do the same.

That is not a segfault. It's because setting the thread name is implemented by raising an exception. You can ignore the exception. (But I think if a debugger doesn't ignore...

I like this idea. This seems to be controlled by this condition: https://github.com/rizonesoft/Notepad3/blob/8061d2ee968185258744887b37be88118ad07677/src/Notepad3.c#L12042

```c++ const char* str = "娴嬭瘯"; ``` 看起来是 GDB 把源码当作 GB18030 了，不过我的系统是全局 UTF-8 的，理论上是不应该有 936 代码页。我记得编译 GDB 的配置里有些 libiconv 的参数，回头找找看。 It looks like GDB misinterprets source code in GB18030. But...

It looks like GDB uses ncurses to display source code, which uses `mbrtowc()` to convert narrow strings to wide strings [^1], which for MSVCRT goes into the private implementation of...

I hope I wouldn't have to repeat myself: If you want sane UTF-8 support, then you _must_ use UCRT. Anything about UTF-8 on MSVCRT is unspecified and unsupported.

GDB (rather, ncurses) knows nothing about the encoding of source files. GDB just calls `setlocale(LC_ALL, "")` and ncurses will take whatever the CRT happens to provide.

One more word: I don't know how native curses programs communicate with mintty. It is possible that mintty allocates a new console for the native GDB, or communicates with GDB...