How to make wchar_t on OSX

Hello, I try to show string "hello - привет" over ncurses (ncursesw) unsafe bridge on OSX platform and meet with misunderstanding or even error.

When I use classic addstr on OSX some char is broke and I think that I should use addwstr but in this case I does not see any chars.

How to prepare wchar_t parameter on OSX platform?

P.S. I see that for Windows system have encode_wide on string any compatible way for OSX or I simple may use OSString for this purposes?

Firstly, it would help to know how you are calling the addstr()/addwstr() function. You mentioned ncursesw, and the addstr() and addwstr() functions of ncursesw take in &str and &WideString respectively, so using those higher-level interfaces may give better handling (and a safer interface). Based on the mention of unsafe and wchar_t, I assume you are trying to use the lower-level functions shims::bindings::addstr() and shims::bindings::addwstr(), which take a *const c_char and *const wchar_t respectively. These types are intended to correspond to the types in C. A c_char is one byte long, but I think it is somewhat implementation-defined as to what happens with non-ASCII characters, so depending on how you are calling addstr() with non-ASCII characters, that may be causing the corrupted characters. The wchar_t type in C on Linux and OS X is 32 bits long (and in general is an implementation-defined type). I believe ncurses takes it to be 32 bits, and wchar_t in ncursesw defnes it to be c_int, which is i32, since it is 32 bits on most systems.

The answer, then is that to make a wchar_t you need 32-bit characters, which the char type already gives you. I would suggest doing something like s.chars().map(|c| u32::from(c) as wchar_t).colllect::<Vec<wchar_t>>() to make a vector of wchar_t (which is basically what WideString::from_str() does), push() a null, then pass a pointer to that using as_ptr(). Using the higher-level addwstr() handles most of that for you.

The encode_wide() function doesn't help here as it encodes into UTF-16, which is how Windows usually deals with wide characters. That isn't the case on Unix-like systems, which usually use UTF-8. However, it appears ncurses uses 32-bit characters for its wide characters, so the conversion to UTF-8 vectors that OsString provides for Unix doesn't help here either.

ncursesw does not compile on OSX with error

I try to port back source code in but receive broke chars in console.

Example code:

There only ASCII chars a visible and does not CRLF in output too.

Found solution. Since ncurses 5.2 library may interpretation output chars over internal locale translation and require invoke setlocale(ALL, "") to escape that interpretation (default: ncurses use LATIN-1). Thanks for support. Problem solved.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.