[PATCH] [3/6] Add support for non-utf8 file names in Path.inc
rnk at google.com
Wed Sep 18 16:52:21 PDT 2013
On Wed, Sep 18, 2013 at 4:41 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
> On Wed, Sep 18, 2013 at 4:25 PM, Yunzhong Gao <
> Yunzhong_Gao at playstation.sony.com> wrote:
>> ygao added you to the CC list for the revision "[3/6] Add support for
>> non-utf8 file names in Path.inc".
>> File names on Windows may be system-locale encoded instead of UTF-8. For
>> example, the default encoding on a Japanese Windows environment is
>> This patch modifies UTF8ToUTF16() to fall back to the OEM code page
>> locale) when UTF-8 fails to match. UTF8ToUTF16() is renamed to
>> to reflect the new reality. This patch allows various llvm::sys::fs
>> like status() or exists() to be applicable on foreign Windows environment.
>> This is part of a bigger effort to support foreign characters in file
>> Could someone take a look whether this is good to go in?
> String encodings aren't a guessing game; you can't just try encodings
> until you find one that works. We shouldn't be passing strings encoded in
> the OEM codepage to the path APIs on Windows; please fix the code that is
> passing in such strings.
Yes, probably the real solution is to define wmain instead of main, so we
can get our hands on Unicode paths to start with, convert that to UTF-8
internally, and go from there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits