Date: Sat, 9 May 2015 11:36:44 +0800 From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com, James McNellis <james@...esmcnellis.com>, austin-group-l@...ngroup.org, Clang Dev <cfe-dev@...uiuc.edu>, blees@...n.de, dplakosh@...t.org, hsutter@...rosoft.com, writeonce@...ipix.org Subject: 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? 2015-05-09 11:32 GMT+08:00 Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.