Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 May 2015 22:15:52 +0800
From: 罗勇刚(Yonggang Luo)  <>
To: Rich Felker <>
Cc: John Sully <>, Karsten Blees <>,,,,, 
	Clang Dev <>, James McNellis <>
Subject: 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?

> 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

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.