[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150508133545.GW17573@brightrain.aerifal.cx>
Date: Fri, 8 May 2015 09:35:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: There is no tests for musl,
On Fri, May 08, 2015 at 09:10:14PM +0800, 罗勇刚(Yonggang 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 msvc.
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 design.
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
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.
