<div dir="ltr">In that case, can this be a follow-up patch (which may not happen immediately)?  It's using the A functions before my patch anyway, so I'm introducing anything that's worse than before.  I can leave a comment in the code that mentions that we need to eventually convert to using W functions, and doing so requires refactoring the registry support code.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 1:43 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron.ballman@gmail.com" target="_blank">aaron.ballman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Oct 17, 2014 at 4:38 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
><br>
> On Fri, Oct 17, 2014 at 1:27 PM, Aaron Ballman <<a href="mailto:aaron.ballman@gmail.com">aaron.ballman@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Oct 17, 2014 at 4:22 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Fri, Oct 17, 2014 at 12:48 PM, Aaron Ballman<br>
>> > <<a href="mailto:aaron.ballman@gmail.com">aaron.ballman@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Fri, Oct 17, 2014 at 3:06 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>><br>
>> >> wrote:<br>
>> >> > -<br>
>> >> >  std::unique_ptr<Command> visualstudio::Compile::GetCommand(<br>
>> >> >      Compilation &C, const JobAction &JA, const InputInfo &Output,<br>
>> >> >      const InputInfoList &Inputs, const ArgList &Args,<br>
>> >> > Index: lib/Driver/WindowsToolChain.cpp<br>
>> >> > ===================================================================<br>
>> >> > --- lib/Driver/WindowsToolChain.cpp<br>
>> >> > +++ lib/Driver/WindowsToolChain.cpp<br>
>> >> > @@ -77,61 +77,59 @@<br>
>> >> >    return getArch() == llvm::Triple::x86_64;<br>
>> >> >  }<br>
>> >> ><br>
>> >> > +#ifdef USE_WIN32<br>
>> >> > +static bool readFullStringValue(HKEY hkey, const char *valueName,<br>
>> >> > +                                std::string &value) {<br>
>> >><br>
>> >> We should be preferring the W versions of these APIs instead of the A<br>
>> >> versions, especially since this is being used to pull out file paths.<br>
>> ><br>
>> > How does this work, since ultimately all of clang uses non-wide<br>
>> > character<br>
>> > strings anyway.  I mean I know how to convert between the two, but I was<br>
>> > under the impression that everything was just already broken because<br>
>> > afaik<br>
>> > we don't ever use W functions anywhere else.<br>
>><br>
>> My understanding is that we use the W versions of the APIs and<br>
>> immediately convert to UTF-8 to store internally. When we require<br>
>> interaction in the other direction, we convert back to UTF-16. At<br>
>> least, this is how we work with things like command line arguments and<br>
>> files. As an example, see Process::GetArgumentVector.<br>
><br>
><br>
> So llvm::sys::windows::UTF8ToUTF16 and its counterpart are not exposed in a<br>
> public header.  Is there an accepted way to re-use them here, or do I need<br>
> to duplicate the code in clang?<br>
<br>
</div></div>There's not an accepted way currently, but duplication isn't the answer either.<br>
<br>
I think the registry code should be pulled down into an LLVM Support<br>
interface that's available on Windows (since we're already using<br>
USE_WIN32 within clang, I don't think the interface needs x-platform<br>
stubs), and the conversion routines hoisted to a place where they can<br>
be exposed for use within Support so that they can be used with the<br>
registry code. Registry use shouldn't be overly widespread, so I think<br>
the abstraction could be fairly simplistic.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br></div>