<div dir="ltr">On Wed, Sep 18, 2013 at 4:25 PM, Yunzhong Gao <span dir="ltr"><<a href="mailto:Yunzhong_Gao@playstation.sony.com" target="_blank">Yunzhong_Gao@playstation.sony.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ygao added you to the CC list for the revision "[3/6] Add support for non-utf8 file names in Path.inc".<br>

<br>
Hi,<br>
<br>
File names on Windows may be system-locale encoded instead of UTF-8. For<br>
example, the default encoding on a Japanese Windows environment is shift-JIS.<br>
This patch modifies UTF8ToUTF16() to fall back to the OEM code page (system<br>
locale) when UTF-8 fails to match. UTF8ToUTF16() is renamed to ExternToUTF16()<br>
to reflect the new reality. This patch allows various llvm::sys::fs utilities<br>
like status() or exists() to be applicable on foreign Windows environment.<br>
This is part of a bigger effort to support foreign characters in file names.<br>
<br>
Could someone take a look whether this is good to go in?<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div></div><div class="gmail_extra">-Eli</div></div>