AFAIK Clang internals do assume utf8, and llvm::sys::path converts strings to utf16 on windows and calls W API functions.<div><br></div><div>If somebody would like to take a look at my changes and comment on them. Here's a brief explanation of what I did:</div>

<div><br></div><div>- Convert argv to utf8 using current system locale for win32 (this is done as soon as possible inside ExpandArgv). This makes the driver happy since calls to llvm::sys::path::exists succeed.</div><div>

- Change calls to ::open (inside FileSystemStatCache and MemoryBuffer) to ::_wopen on win32 by converting the path to utf16.</div><div>- In order to do the conversions I had to expose two functions, one of them was already there but wasn't visible, the other one was added by me</div>

<div><br></div><div>Known issues:</div><div><br></div><div>- I should probably use LLVM_ON_WIN32 instead of WIN32 but this macro isn't defined inside FileSystemStatCache and MemoryBuffer for some reason. Both of these files have an #ifdef section that deals with O_BINARY so maybe these two sections should be consolidated?</div>

<div>- Functions convert_multibyte_to_utf8 and convert_utf8_to_utf16 have definitions only on windows so every other platform is currently broken.</div><div><br></div><div><div class="gmail_quote">On Thu, Sep 1, 2011 at 5:44 PM, 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>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</p></blockquote></div></div>