From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7606 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?= Newsgroups: gmane.comp.standards.posix.austin.general,gmane.linux.lib.musl.general,gmane.comp.compilers.clang.devel 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? Date: Sat, 9 May 2015 11:16:37 +0800 Message-ID: Reply-To: luoyonggang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1431141437 5506 80.91.229.3 (9 May 2015 03:17:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 May 2015 03:17:17 +0000 (UTC) To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org, James McNellis , austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org, Clang Dev , blees-x8bNZE/nUJk@public.gmane.org, dplakosh-etTNj8cnB6w@public.gmane.org, hsutter-0li6OtcxBFHby3iVrkZq2A@public.gmane.org, writeonce-noBqTzJW0ZJAfugRpC6u6w@public.gmane.org Original-X-From: austin-group-l-request-7882/jkIBncuagvECLh61g@public.gmane.org Sat May 09 05:17:16 2015 Return-path: Envelope-to: gcsa-austin-group-l-wOFGN7rlS/M9smdsby/KFg@public.gmane.org Original-Received: from m4.opengroup.org ([64.79.149.154]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YqvGM-0007D3-Np for gcsa-austin-group-l-wOFGN7rlS/M9smdsby/KFg@public.gmane.org; Sat, 09 May 2015 05:17:15 +0200 Original-Received: (qmail 22817 invoked by uid 503); 9 May 2015 03:17:07 -0000 Resent-Date: 9 May 2015 03:17:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=VESPKR3kReOGKah9FaW2romqomLmF7gDb7MQ7XQn3vQ=; b=RGjGH3WYC0XX/2VIlqJ3Ry0/UPIiOWtKN4HypOCCoUNX04QfFqcIJrqopU50XVTXkM gLXxlTMnQwhcm6YYgR3W/Um/OGyNdHExn0GygG8RCiLt3D1KgDTktJdfKmoC2HHjBh+5 sDFfJICyrmnY07fcc4EuI3ZSfcAbNaSKEjyxVlTt0A20h5ZEXds5VjCyjNCI6+ZrJbkl r0Cme3/fUL/TVN3G1M9urzc/YE5/IBlL3hdeKY3JPmcAKxJ8BFjcjaS+JogugzjFJt5u gaZ8e/TuMwZ1SitJe4ApMXS43v4baTdwO9BaHXfJ9E+16lzfPuvesI3ouE+1667oZzZK wHnw== X-Received: by 10.107.12.158 with SMTP id 30mr1146988iom.61.1431141417953; Fri, 08 May 2015 20:16:57 -0700 (PDT) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-3.0 (m1.opengroup.org [172.20.55.20]); Fri, 08 May 2015 20:16:58 -0700 (PDT) X-Spam-Flag: NO X-Scanned-By: milter-spamc/0.25.320 (mimas [172.20.55.20]); Fri, 08 May 2015 20:17:02 -0700 X-Spam-Status: NO, hits=-3.60 required=5.00 X-Spam-Level: X-Virus-Scanned: clamav-milter 0.98 at m1.opengroup.org X-Virus-Status: Clean X-MIME-Autoconverted: from quoted-printable to 8bit by m4.opengroup.org id t493H2QB022732 Resent-Message-ID: <"BoilpC.A.njF.ywXTVB"@Phoebe.vpn.opengroup.org> Resent-To: austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org Resent-From: austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org X-Mailing-List: austin-group-l:archive/latest/22428 X-Loop: austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org Precedence: list Resent-Sender: austin-group-l-request-7882/jkIBncuagvECLh61g@public.gmane.org Xref: news.gmane.org gmane.comp.standards.posix.austin.general:10756 gmane.linux.lib.musl.general:7606 gmane.comp.compilers.clang.devel:42663 Archived-At: 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 >> >> >> > >