[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 May 2015 11:25:40 +0800
From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>
To: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>,
Rich Felker <dalias@...c.org>, 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?
2015-05-11 9:47 GMT+08:00 Mike Frysinger <vapier@...too.org>:
> On 10 May 2015 20:31, 罗勇刚(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,
>
> POSIX has no such encoding requirement on the |path| argument:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
>
> on Linux, that buffer is a standard NUL-terminated C string which is passed
> directly to the kernel which more or less passes it directly to the fs driver.
> how some FS drivers interpret that string depends on the FS.
> -mike
In linux world, the encoding of path is dependent to FS, that's true:)
Even though at nowadays, major FS are UTF-8 as default encoding.
But in Win32 world, that's different things, the Win NTFS are using
UTF16 for the FS, but under different system locale, (GBK or CP1252)
it's would using different encoding(GBK or CP1252) to open the same file.
That's make the open function useless on win32.
--
此致
礼
罗勇刚
Yours
sincerely,
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.
