Re: Is that getting wchar_t to be 32bit on win32 a good idea for compatible with Unix world by implement posix layer on win32 API?

["罗勇刚(Yonggang Luo) " <luoyonggang@gmail.com>]

2015-05-09 11:32 GMT+08:00 Rich Felker <dalias@libc.org>:
> On Sat, May 09, 2015 at 11:16:37AM +0800, 罗勇刚(Yonggang Luo)  wrote:
>> Two solution:
>> 1、Change the width of wchar_t to 16 bit, I guess that would broken a
>> lot of things that exist on Win32 world.
>> 2、Or we should preserve wchar_t to be 16 bit on win32, and add the
>> char16_t and char32_t
>> variant API for all API that have both narrow and wide version?
>>
>>
>> I support for the second one, even if the second option is not
>> applicable. the first option would cause a lot problems, the first
>> thing is all Windows API use wchar_t and dependent on the wchar_t to
>> be 2 byte width.  Second is, there is open source libraries that
>> dependent the de fac·to that wchar_t to be 16 bit, such as Qt,
>> Git(maybe).
>> Almost exist open source libraries that already ported to Win32 are
>> dependent the the fact wchar_t to be 16 bit,  cygwin is also discussed
>> if getting wchar_t to be 32bit on win32
>>
>> https://www.cygwin.com/ml/cygwin/2011-02/msg00037.html
>
> Well, which option is an easier path forward depends on your main
> usage case. If you're most concerned about building existing
> Windows-targetted code unmodified, obviously doing the same thing MSVC
> does, even if it's a bad design, achieves that.
>
> On the other hand, if your goal is building software that was written
> for POSIX or POSIX-like systems on Windows with little or no
> modification, it's more complicated. Code that currently has no
> Windows support certainly will work best (full Unicode support) with
> 32-bit wchar_t. Code that already has Windows-specific workarounds
> (assuming wchar_t is 16-bit on Windows) needs those undone to make it
> work. But such code _should_ be checking WCHAR_MAX instead of assuming
> Windows is 16-bit. I believe midipix is dealing with this issue simply
> by not predefining _WIN32 or whatever, so that none of the Windows
> workarounds will get activated.
>
> I really suspect most Windows code interfacing with WINAPI is using
> WCHAR, not wchar_t, for its UTF-16 strings. So fixing wchar_t to be
This is a misunderstanding,
The real definition of WCHAR is in winnt.h, and defined as follow:

#ifndef _MAC
typedef wchar_t WCHAR;    // wc,   16-bit UNICODE character
#else
// some Macintosh compilers don't define wchar_t in a convenient
location, or define it as a char
typedef unsigned short WCHAR;    // wc,   16-bit UNICODE character
#endif



> 32-bit and leaving WCHAR alone is the best solution in my opinion.
> Note that you're still left with the issue that L"xxx" strings will
> not work with WCHAR, but this really only matters if you're trying to
> use existing Windows-targetted code unmodified, and it's easily fixed
> by s/L"/u"/g across the source (making them char16_t[] literals rather
> than wchar_t[] literals).
>
> I don't think adding lots of functions for char16_t and char32_t is
> useful. The format you want programs to be using is UTF-8. With
> midipix all of the standard C functions, just like in straight musl,
> always work in UTF-8, and there are also wrappers for the WINAPI that
> convert UTF-8 to UTF-16 transparently. This allows you to just work in
> char[] strings and pass them to WINAPI functions like you would if you
> were working in "ANSI codepage" mode, except that you actually have
> full Unicode available. I strongly support this approach and hope
> you'll adopt it.
>
> Rich



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo