Date: Fri, 8 May 2015 23:32:32 -0400 From: Rich Felker <dalias@...c.org> To: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com> 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? 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 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
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.