[cfe-dev] [musl] Re: 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?

罗勇刚(Yonggang Luo) luoyonggang at gmail.com
Tue May 12 18:03:08 PDT 2015

2015-05-13 5:57 GMT+08:00 Shware Systems <shwaresyst at aol.com>:
> (received via austin-group-l)
> My 2 cents:
> Yes, it is a good idea, having wchar_t be 32-bits. For some simple
> transforms of a few current 8-bit oriented multi-byte code sets, a wchar_t
> of 64 bits is actually desirable to simplify and speed up some operations,
> from a conceptual standpoint. Conversions to and from char32_t type would be
> slower. A 32-bit wchar_t, based on uint32_t type, also has similar
> applications in processing UTF16 strings, whether based on char16_t type of
> C11, or byte or short arrays. If anything, POSIX needs to expand wchar_t
> support, not drop it, so systems like Windows are more subsets of POSIX in
> function than incompatible. Such integration is one of the tentative goals
> identified as desirable for Issue 8; how well it gets accomplished remains
> to be seen :-). In some respects it's a more massive undertaking than the
> efforts made for Issue 6 integrating Unix and POSIX because of various
> legacy compatibility issues, that I can see.
So are you suggesting wchar_t to be 64 bit? From my point of view, for
not breaking exist thing, maintain the size of wchar_t to not be
changed, and on different platform use different size,
and introduce new types such as char32_t and even char64_t to do
platform-neutral things would be a better option.
wchar_t's size is decided by the compiler and that would not changed
by our discussing.
Yonggang Luo

More information about the cfe-dev mailing list