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 08:31:54PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> For example, the open function exist both in msvcrt and posix,
> int open(const char *path, int oflag, ...);
> 
> But in msvcrt, the path is ANSI encoding, and in posix, path is utf8 encoding,
> 
> So if we need to developing a cross-platform application, On Win32,
> the open function should not be used.
> But in fact, there is no openw(const wchar*path) API in posix or Win32,
> So we need to re-implement open function on win32 with the same API,
> and convert to
> the wchar_t version of Window 32 API, _wopen,
> That's would be a chaos for those developers want to use open function
> in both posix and win32.

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.

Rich