_wopen expects wchar_t* and the only visible function for conversion to utf16 is ConvertUTF8toUTF32 which converts to unsigned shorts. There is a function that does exactly what I need called UTF8ToUTF16, but it's inside an anonymous namespace inside windows version of PathV2.inc<div>
<br></div><div>I could solve this in a number of ways, but I'm not sure which one is preferred inside Clang codebase?</div><div><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 1:25 AM, Ruben Van Boxem <span dir="ltr"><<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Op 25 aug. 2011 00:08 schreef "Nikola Smiljanic" <<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>> het volgende:</p>
<div class="im"><br>
><br>
> I'm trying to fix unicode file handling on windows <a href="http://llvm.org/bugs/show_bug.cgi?id=10348" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=10348</a>. This currently doesn't work because argv is encoded as multibyte string (clang project is configured this way). <br>
><br>
> Michael suggested converting command line to utf8, and this indeed solves the error that the driver emits, but there is another check in CompilerInstance that fails because FileSystemStatCache::get calls ::open and I'm guessing that this function is not smart enough to handle utf8 path on windows? Any ideas?</div>
<p></p>
<p>It's not smart enough no, but you can use _wfopen instead. Note that all of its arguments are wchar_t*</p>
<p>Ruben</p><div><div></div><div class="h5"><br>
><br>
> I have one more question. I added MultibyteToUTF8 function to PathV2.inc (windows version) and now I'd like to call it from ExpandArgv (driver.cpp) but this code is platform specific and isn't visible (function is inside anonymous namespace). I could create a wrapper function that calls this function on windows and does nothing on other platforms. Is this the way to go, and where should I put it (llvm::sys::fs, llvm::sys::path or somewhere else)?<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Michael Spencer <<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>><br>
> Date: Sat, Jul 16, 2011 at 12:32 AM<br>
> Subject: Re: Question regarding Clang path handling on Windows<br>
> To: Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>><br>
><br>
><br>
> On Thu, Jul 14, 2011 at 8:25 AM, Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>> wrote:<br>
> > Hi Michael I'd like to fix this bug if I<br>
> > can <a href="http://llvm.org/bugs/show_bug.cgi?id=10348" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=10348</a>. Started looking around and I<br>
> > think I know where the problem is (your name showed up in svn log for<br>
> > PathV2.inc), but I'm not sure what is the right way to solve it. Namely, the<br>
> > check in Driver::BuildActions (line 772) fails. It seems<br>
> > that function llvm::sys::fs::exists tries to convert input string from utf8<br>
> > to utf16, but clang.exe is compiled with Multibyte Character Sets. This<br>
> > means that the conversion will succeed when you pass an ANSI string that is<br>
> > also a valid utf8 string. But if you try to pass in some Chinese characters<br>
> > you'll get a single byte character string that is interpreted using the<br>
> > current windows locale, and in this case conversion from utf8 to utf16 will<br>
> > fail (character values are negative). So my question is whether this<br>
> > function should do the conversion at all, maybe there are other places in<br>
> > the code that can call it with utf8 input that is obtained from some windows<br>
> > function? In this particular case, conversion should be done using the<br>
> > current locale. I'd like to hear what you think?<br>
><br>
> This was an oversight on my part. I assumed the command line would be<br>
> in utf8 for some reason. Clang internals currently assume utf8, so the<br>
> correct fix is to convert the command line to utf8 first. I'll look<br>
> into adding this.<br>
><br>
> - Michael Spencer<br>
><br>
><br>
><br></div></div>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
<p></p>
</blockquote></div><br></div>