Re: 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?

[Rich Felker <dalias@libc.org>]

On Sun, May 10, 2015 at 10:15:52PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> >
> > 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.

I understand that you've made this claim multiple times, but with no
evidence/data to back it up. From my perspective, what you're saying
is that having more uniformity between platforms, and being able to
use the same interface on them all rather than having to use
platform-specific APIs, "makes chaos for developers...making true
cross-platform apps and libs". In the absence of specific reasons to
believe that, one would tend to believe the opposite.

Rich