From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7596 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: There is no tests for musl, Date: Fri, 8 May 2015 22:17:58 +0800 Message-ID: References: <20150508080122.GC29035@port70.net> <20150508083641.GD29035@port70.net> <20150508124942.GV17573@brightrain.aerifal.cx> <20150508133545.GW17573@brightrain.aerifal.cx> <20150508141013.GX17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1431094726 13995 80.91.229.3 (8 May 2015 14:18:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 May 2015 14:18:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7609-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 08 16:18:32 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Yqj6m-0005Zn-FS for gllmg-musl@m.gmane.org; Fri, 08 May 2015 16:18:32 +0200 Original-Received: (qmail 13865 invoked by uid 550); 8 May 2015 14:18:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13844 invoked from network); 8 May 2015 14:18:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=TXOdZZSWMnSI+VOzv26gVQnviyFdumpb9R8tfUKW0yU=; b=TYu6507iTQVhcmZXJPMs6Keil1wUcpFyz9L0IKnllMuTgdJ9aVXhLPZT4I6XcWhJGk BB9317O6MluODks1M50UmlEBsRFAqOcxtxMecumvdlXcKV8oAZkstlcLv+av79vQmkxj G7aW9UG9uGvdzQerCr2Elv/vSIEeLdEIDLZMYMMCgiZO8gxp1HnARFzEyC7oMjHgW0e4 P0D1kjTCM378zewz/ygQ6mIXkSr8BE4o2P/1TFYdpQ/NzsyZenGWEniQncGPWOMxOCC0 FUQYllbmhoDdB9wvsIMFlSHXmQ8MKz7g8Un19ey2YzdVQHhh/RkYyytPelgkiK4WYoGI 8Yow== X-Received: by 10.43.133.137 with SMTP id hy9mr4284982icc.74.1431094698565; Fri, 08 May 2015 07:18:18 -0700 (PDT) In-Reply-To: <20150508141013.GX17573@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7596 Archived-At: 2015-05-08 22:10 GMT+08:00 Rich Felker : > On Fri, May 08, 2015 at 10:02:53PM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(Yon= ggang Luo) wrote: >> Thanks for the detail explain, I know all the shortcut of 16bit >> wchar_t, considerate that 4bit wchar_t is rarely used in unix world, >> but 16bit wchar_t is frequently in >> Windows/Qt/Java/Javascript, so I think it's better not change the >> 16bit wchar_t to 32 bit, and that's would confusing those people >> already use 16bit wchar_t on Windows platform, and this would affect >> Unix- world, by default, on win32, wchar_t is 16 bit, this is a de >> facto. > > That's a choice you can make in the system you're developing, but you > should be aware that it makes it impossible to support full Unicode > with the standard APIs and thus requires apps to either limit > themselves to supporting only the BMP or using nonstandard APIs. > >> >From this point of view, getting wchar_t to be 32bit on win32 is >> useless and cause more problems. >> The main point to port musl on win32 is add posix support and utf8 >> support on win32. >> The wchar_t is useless for those people need cross-platform text >> processing, and should using char32_t instead. That's a design >> principle. > > Again, char32_t can't support full Unicode if wchar_t is only 16-bit. > It's stuck supporting just the BMP and the upper 16 bits are always > zeros. Any attempt to make char32_t support the full range would > produce inconsistent and nonconforming results. :( I can predict the shortcoming of this, and there is a lot of ways to resolve this, anyway, for win32, preserve the original wchar_t semantics is the best solution, I think there is no one would use wchar_t for cross text processing, cause, on some system, wchar_t is just 8bit width! for some os platform:( refere to http://en.wikipedia.org/wiki/Wide_character#Programming_specifics We should not use wchar_t for cross-platform text processing. Anyway, deal with ANSI things on win32 is the maddest things on the world, cause wchar_t at lease is Unicode after all:) either utf8,utf16 or utf32. > > Rich --=20 =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo