[PATCH] [3/6] Add support for non-utf8 file names in Path.inc

Reid Kleckner 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".
>>
>> Hi,
>>
>> File names on Windows may be system-locale encoded instead of UTF-8. For
>> example, the default encoding on a Japanese Windows environment is
>> shift-JIS.
>> This patch modifies UTF8ToUTF16() to fall back to the OEM code page
>> (system
>> locale) when UTF-8 fails to match. UTF8ToUTF16() is renamed to
>> ExternToUTF16()
>> to reflect the new reality. This patch allows various llvm::sys::fs
>> utilities
>> like status() or exists() to be applicable on foreign Windows environment.
>> This is part of a bigger effort to support foreign characters in file
>> names.
>>
>> 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...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130918/4de03b82/attachment.html>


More information about the llvm-commits mailing list