Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE2XoE8zGe-Pk41V7aLnA9x3o-J2fq5VvwCe8PWK52y4k2rhpg@mail.gmail.com>
Date: Fri, 8 May 2015 21:10:14 +0800
From: 罗勇刚(Yonggang Luo)  <luoyonggang@...il.com>
To: musl@...ts.openwall.com
Subject: Re: There is no tests for musl,

I've seen all the codes of midipix, it's seems not active developing now.
I was trying to the other way, that getting musl can be compiled with msvc.
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.


2015-05-08 20:49 GMT+08:00 Rich Felker <dalias@...c.org>:
> On Fri, May 08, 2015 at 04:52:28PM +0800, 罗勇刚(Yonggang Luo)  wrote:
>> That's looks good, except the wchar_t part.
>> I am not so sure that's was a good idea, cause all Windows API wchar_t
>> are UTF16...
>
> It's necessary to support all of Unicode and not just the BMP.
>
> On midipix you still have all the raw Windows API functions that need
> UTF-16 "WCHAR" arrays as input, so you can convert manually to WCHAR
> (which happens to also match the standard C type char16_t) and call
> them. But there's also a wrapper layer that lets you pass UTF-8
> strings to WinAPI wrappers, so you never have to deal with wchar_t or
> WCHAR at all. I don't know all the details but you could ask on
> #midipix.
>
> Rich



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
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.