<p>Op 1 sep. 2011 14:12 schreef "NAKAMURA Takumi" <<a href="mailto:geek4civic@gmail.com">geek4civic@gmail.com</a>> het volgende:<br>
><br>
> Guys, welcome to the too weird i18n world!<br>
> We, Japanese, has got suffered for multibyte charset for 20 years.<br>
><br>
> I have added a comment in <a href="http://llvm.org/bugs/show_bug.cgi?id=10348">http://llvm.org/bugs/show_bug.cgi?id=10348</a> .<br>
> Of course I know, I don't think it would be a practical resolution.<br>
><br>
> FYI, it seems clang can retrieve mbcs path with s/CP_UTF8/CP_ACP/g.<br>
><br>
> E>bin\clang.exe -S なかむら\たくみ.c<br>
> なかむら\たくみ.c:4:2: error: #error<br>
> #error<br>
>  ^<br>
> 1 error generated.<br>
><br>
> Though, you should know, MBCS still has an issue;<br>
><br>
> E>bin\clang.exe -S 表はダメ文字\表はダメ文字.c<br>
> clang: error: no such file or directory: '表はダメ文字\表はダメ文字.c'<br>
> clang: error: no input files<br>
><br>
> Note, "表" is represented as "0x95 0x5C" in CP932.<br>
><br>
> In principle, IMHHHO;<br>
><br>
>  - argv should be treated as "blackbox" byte stream.<br>
>  - Don't assume "wmain(argc, wchar_t **argv)". mingw does not have<br>
> one. Then, argv must be presented as the default codepage.</p>
<p>Correction: I believe MinGW-w64 has a Unicode startup and thus support for wmain (but of course it would be better to shift this to strict API functions)</p>
<p>>  - A few codepage (eg. cp932 Japanese shift jis) might contain<br>
> 0x5C(\) in 2nd (leading) octet.<br>
><br>
> Win32 ANSI (****A) APIs assume local codepage.<br>
><br>
> We should do in llvm;<br>
><br>
>  - Treat pathstring in argv as blackbox. Never parse<br>
> (char*)pathstring without any knowledge.<br>
>  - UTF8 would be useless on win32. Win32 does not manipulate utf8<br>
> implicitly in anywhere.<br>
>  - Path API should hold pathstring as API-native form (bytestream on<br>
> unix, UCS2 wchar_t on win32).<br>
>  - Path should be manipulated as API-native form as possible.</p>
<p>Isn't it more straightforward to use utf-8 internally and use the conversion functions provided by the win32 API when calling other win32 API functions, and always call the wide versions of the win32 functions. Full compatibility guaranteed, and one encoding internally.</p>

<p>Ruben<br>
><br>
> In future, we might consider "-finput-charset" and "-fexec-charset" on clang.<br>
> Please consider an source file;<br>
><br>
> ////////<br>
> #include "むすめは/まおちゃん.h"<br>
> char const literal[] = "俺です、俺俺";<br>
> ////////<br>
><br>
> The include path (#include) should be handled as host-dependent. The<br>
> literal should be interperted with input-charset and be emitted with<br>
> exec-charset.<br>
><br>
> Too hard the life is. Would you like to live in Japan? :p<br>
><br>
><br>
> ...Takumi<br>
><br>
><br>
> 2011/9/1 Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>>:<br>
> > The function available in clang/lib/Basic/ConvertUTF.c deals with unsigned<br>
> > shorts, and I need wchar_t?<br>
> ><br>
> > On Thu, Sep 1, 2011 at 9:36 AM, Jean-Daniel Dupas <<a href="mailto:devlists@shadowlab.org">devlists@shadowlab.org</a>><br>
> > wrote:<br>
> >><br>
> >> Le 31 août 2011 à 21:02, Aaron Ballman a écrit :<br>
> >><br>
> >> > On Wed, Aug 31, 2011 at 1:17 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>><br>
> >> > wrote:<br>
> >> >> On Wed, Aug 31, 2011 at 10:58 AM, Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>><br>
> >> >> wrote:<br>
> >> >>> _wopen expects wchar_t* and the only visible function for conversion<br>
> >> >>> to<br>
> >> >>> utf16 is ConvertUTF8toUTF32 which converts to unsigned shorts.<br>
> >> >><br>
> >> >> If you're in #ifdef WIN32 code, just use ConvertUTF8toUTF16 and<br>
> >> >> reinterpret_cast from unsigned short* to wchar_t*.<br>
> >> ><br>
> >> > I think the problem is that PathV2.inc is part of LLVM, and the<br>
> >> > ConvertUTF8ToUTF16 function is in an anonymous namespace.  So the<br>
> >> > question becomes: raise the function into an accessible namespace,<br>
> >> > duplicate code, or find some other mechanism?<br>
> >><br>
> >> This function is also available in clang/lib/Basic/ConvertUTF.c<br>
> >><br>
> >> ><br>
> >> > I don't think it makes sense to raise the function out of the<br>
> >> > anonymous namespace unless it's also moved (it has nothing to do with<br>
> >> > paths per se).  Perhaps it's worth it to move it to StringRef?<br>
> >> ><br>
> >> > ~Aaron<br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > cfe-dev mailing list<br>
> >> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> >> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> >><br>
> >> -- Jean-Daniel<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> cfe-dev mailing list<br>
> >> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> ><br>
> ><br>
</p>