[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
Sun May 10 07:15:52 PDT 2015

> I assumed you were already planning for your POSIX layer an open
> function which takes a UTF-8 string and converts it transparently to
> whatever encoding (i.e. UTF-16) the underlying Windows operations
> need. If you don't have that, then you're a step behind even Cygwin
> and significantly behind midipix in terms of the ability to provide a
> POSIX+Unicode environment that can run existing POSIX-targeted
> applications unmodified. Anyone wanting Unicode filename support would
> have to fill their codebase with Windows-specific openw() calls, which
> is basically the same situation you have now on Windows.
>> And if we turn the wchar_t to be 32 bit on win32,
>> first, posix still have no wide version of open function
>> second, to implement open function on win32, we need to consider the
>> fact wchar_t is 32bit now, and should re-use the exist _wopen in
>> a different way and all other exist wide version of Win32 API.
> I don't follow what you're saying here.
My point is that getting wchar_t  to be 32bit on win32 would making
chaos for those developers.
who want to making true cross-platform apps and libs, your though is
too restricted to
unix-like system, but not thinking things in a objective manner.
> Rich

Yonggang Luo

More information about the cfe-dev mailing list