Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE2XoE8M1nxo=bCH0opS4unTUuZLmGYgRHOXRHLb6gszqRviZw@mail.gmail.com>
Date: Sat, 9 May 2015 19:19:14 +0800
From: 罗勇刚(Yonggang Luo)  <luoyonggang@...il.com>
To: John Sully <john@...uare.ca>, 勇刚 罗 (Yonggang Luo) <luoyonggang@...il.com>, 
	Karsten Blees <blees@...n.de>, musl@...ts.openwall.com, dplakosh@...t.org, 
	austin-group-l@...ngroup.org, hsutter@...rosoft.com, 
	Clang Dev <cfe-dev@...uiuc.edu>, James McNellis <james@...esmcnellis.com>
Subject: Re: [cfe-dev] Is that getting wchar_t to be 32bit on win32 a good
 idea for compatible with Unix world by implement posix layer on win32 API?

2015-05-09 18:36 GMT+08:00 Szabolcs Nagy <nsz@...t70.net>:
> * John Sully <john@...uare.ca> [2015-05-09 00:55:12 -0700]:
>> In my opinion you almost never want 32-bit wide characters once you learn
>> of their limitations.  Most people assume that if they use them they can
>> return to the one character -> one glyph idiom like ASCII.  But Unicode is
>
> wchar_t must be at least 21 bits on a system that spports unicode
> in any locale: it has to be able to represent all code points of the
> supported character set.
>
> in practice this means that the only conforming definition to iso c
> (and thus posix, c++ and other standards based on c) is a 32bit wchar_t
> (the signedness can be choosen freely).
>
> so the definition is not based on what "you almost never want" or what
> "most people assume".
>
> if the goal is to provide a posix implementation then 16bit wchar_t
> is not an option (assuming the system wants to be able to communicate
> with the external world that uses unicode text).
wchar_t is not the only way to communicate with the external way, and
it's also not suite for communicate to the external world,
from the C11 standard, it's never restrict the wchar_t's width, and
for Posix, most API are implement in
utf8, and indeed, Windows need the posix layer mainly because of those
API that using utf8, not wchar_t APIs,
for the communicate reason to getting wchar_t to be 32 bit on Win32 is
not a good idea,

And for portable text processing(Including win32) apps or libs, they
would and should never dependents on the wchar_t must be 32 bit width.

And C11/C++11 already provide uchar.h to provide cross-platform
char16_t and char32_t, so there is no reason to getting wchar_t to be
32bit
on win32 for suport posix on win32.


We were intent to creating a usable posix layer on win32, not creating
a theoretical POSIX layer that would be useless, on win32, we should
considerate the de facto things
on win32.


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