From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7594 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:02:53 +0800 Message-ID: References: <20150508080122.GC29035@port70.net> <20150508083641.GD29035@port70.net> <20150508124942.GV17573@brightrain.aerifal.cx> <20150508133545.GW17573@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 1431093811 30118 80.91.229.3 (8 May 2015 14:03:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 May 2015 14:03:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7607-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 08 16:03:31 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 1YqisC-0007Nr-9c for gllmg-musl@m.gmane.org; Fri, 08 May 2015 16:03:28 +0200 Original-Received: (qmail 5237 invoked by uid 550); 8 May 2015 14:03:26 -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 5213 invoked from network); 8 May 2015 14:03:26 -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=aw0n6dYoR/rNckzjHXuX0KXs4HcEyxBQMKYUTPYbWUY=; b=i7sWVvccl8vo9q2rtPhnsYJcKv/ugqxsXq1cbga810Hak3gEGAMYuHhgUqwRWkUXeV b6BXRLTB2lPg7Ra/LVQhf13R9Wevw45+rbIKHtq8c4Eu1u68X09ZcHMlkFYXzsW2ITNi b8GzRHnNiqPgOirntEU/7uEPLSu3nfrPhAmQLrCfpsi6b5hblRIGQdTJBJS2PKQWYIu0 1iI/RlFnbX++Lh4qtU8Jagc32W5xDqfGX6eVVfmAex/jPakGnPzfB/MovzflFtiIHUPS /cO0M0AwO3/TBfAHHjCAdYd5N7CXB+jv9bGTGVW8L0zvljKb29fEZ1oNhoRFXVUluSzJ 3gMg== X-Received: by 10.50.77.48 with SMTP id p16mr4574878igw.31.1431093794409; Fri, 08 May 2015 07:03:14 -0700 (PDT) In-Reply-To: <20150508133545.GW17573@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7594 Archived-At: 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. >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. 2015-05-08 21:35 GMT+08:00 Rich Felker : > On Fri, May 08, 2015 at 09:10:14PM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(Yon= ggang Luo) wrote: >> I've seen all the codes of midipix, it's seems not active developing now= . > > Perhaps you mean not finished/available rather than not active. It's > very active. > >> I was trying to the other way, that getting musl can be compiled with ms= vc. > > That's unlikely to be possible since MSVC is not a C compiler; it's a > C++ compiler that supports a variant of C that's basically just a > subset of C++. Since the license is free you're welcome to do your own > work taking code from musl and making it work on MSVC, but patches for > MSVC compatibility won't be acceptable upstream. > >> For easily debugging on win32 and preserve the wchar_t on Win32. >> >> I know the advantage of wchar_t to be 32bit, but I think this would be >> double-edged. >> Cause 16 bit wchar_t doesn't not good for Linux, but also 32bit >> wchar_t doesn't good for >> Win32. >> We should leave the all of Unicode to the work of char32_t. That's my de= sign. > > If wchar_t is 16-bit then you _can't_ support all of Unicode, at all. > The C language is such that all defined characters must have > representations in wchar_t, and "multi-wchar_t-characters" are > fundamentally not possible due to the API (and this is stated > explicitly, too). MS ignores this by deprecating the standard C > language functions and providing their own WinAPI functions you have > to use instead. > > Rich --=20 =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo