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
addwstr() function. You mentioned
ncursesw, and the
addwstr() functions of
ncursesw take in
&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::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
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
push() a null, then pass a pointer to that using
as_ptr(). Using the higher-level
addwstr() handles most of that for you.
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 https://github.com/narfit66/ncursesw-rs/issues/5
I try to port back source code in https://github.com/vit1251/ncurses-rs/commits/master but receive broke chars in console.
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.