<div dir="ltr">On Wed, Sep 18, 2013 at 4:41 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.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"><div dir="ltr"><div class="im">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><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><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><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></div></div></blockquote><div><br></div><div>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.</div>
</div></div></div>