[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
