Date: Sat, 9 May 2015 11:16:37 +0800 From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com> To: 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: 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? 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 > think there is no one would use >>>>> wchar_t for cross text processing, cause, on some system, wchar_t is >>>>> just 8bit width! >>>> >>>> anybody would use wchar_t who cares about standard conformant >>>> implementations. >>>> >>>> non-standard broken platforms may get an unmaintained #ifdef >>>> as usual.. >>> >>> I think we (and midipix) have a different perspective from Yonggang >>> Luo on portable development. Our view is that you write to a POSIX (or >>> nearly-POSIX) target with fully working Unicode support and fix the >>> small number of targets (i.e. just Windows) that don't already provide >> Small is relative, if counting the distribution count, well, Unix wins. >>> these things. Yonggang Luo's perspective seems to be more of a >>> traditional Windows approach with #ifdef and lots of OS-specific code, >>> but just making the Windows branch of the #ifdefs less hideous than it >>> was before. :) >> If getting wchar_t to be 32 bit on win32, then truly will be a lot of >> #ifdef, I am not so sure >> if you have experience on Win32 API development, I hope we discussing >> the problems in a >> more objective way. >> > > One primary objective of code portability and posix-compatibility layer > for win32 is to _remove_ the need for OS-specific code-paths. A wchar_t > that is anything short (no pun intended) of a 32-bit integer will render > it impossible to build out of the box many pieces of commonly-used > software, including, but not limited to musl libc, the curses library, > and anything that expects wchar_t to cover the entire unicode range. > > As for your suggested framework: there are currently at least three > compilers that can produce optimized code for the target platform (gcc, > clang, and cparser), and which work very well with most open-source > software out there. As an aside, if you are interested in an 8-byte long > on 64-bit windows then an open-source compiler is probably your only > option. To compile musl with msvc, on the other hand, you'd have to make > so many changes to the source code that you might as well write your own > libc from scratch. To see why, please attempt to compile some ten or > fifteen core libc headers (stdio.h, unistd.h, etc.) with msvc. If that > goes well (spoiler: it won't), then the next step would be to compile a > subset of the source files (src/pthread or src/stdio, for instance) and > remove any remaining obstacles. > > m. > > >>> >>> 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.