Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 May 2015 22:02:53 +0800
From: 罗勇刚(Yonggang Luo)  <>
Subject: Re: There is no tests for musl,

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

>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

2015-05-08 21:35 GMT+08:00 Rich Felker <>:
> 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

Yonggang Luo

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.