musl - 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?

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE2XoE8ARm6BkarKYspPK_uDkePw8PewHXPWRXmT+mGM5mwEaw@mail.gmail.com>
Date: Sun, 10 May 2015 20:31:54 +0800
From: 罗勇刚(Yonggang Luo)  <luoyonggang@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: John Sully <john@...uare.ca>, Karsten Blees <blees@...n.de>, musl@...ts.openwall.com, 
	dplakosh@...t.org, austin-group-l@...ngroup.org, hsutter@...rosoft.com, 
	Clang Dev <cfe-dev@...uiuc.edu>, James McNellis <james@...esmcnellis.com>
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?

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.

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.

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.