[PATCH] Improve Windows toolchain support for non-standard environments.

[Aaron Ballman]

On Fri, Oct 17, 2014 at 4:22 PM, Zachary Turner <zturner at google.com> wrote:
>
>
> On Fri, Oct 17, 2014 at 12:48 PM, Aaron Ballman <aaron.ballman at gmail.com>
> wrote:
>>
>> On Fri, Oct 17, 2014 at 3:06 PM, Zachary Turner <zturner at google.com>
>> wrote:
>> > -
>> >  std::unique_ptr<Command> visualstudio::Compile::GetCommand(
>> >      Compilation &C, const JobAction &JA, const InputInfo &Output,
>> >      const InputInfoList &Inputs, const ArgList &Args,
>> > Index: lib/Driver/WindowsToolChain.cpp
>> > ===================================================================
>> > --- lib/Driver/WindowsToolChain.cpp
>> > +++ lib/Driver/WindowsToolChain.cpp
>> > @@ -77,61 +77,59 @@
>> >    return getArch() == llvm::Triple::x86_64;
>> >  }
>> >
>> > +#ifdef USE_WIN32
>> > +static bool readFullStringValue(HKEY hkey, const char *valueName,
>> > +                                std::string &value) {
>>
>> We should be preferring the W versions of these APIs instead of the A
>> versions, especially since this is being used to pull out file paths.
>
> How does this work, since ultimately all of clang uses non-wide character
> strings anyway.  I mean I know how to convert between the two, but I was
> under the impression that everything was just already broken because afaik
> we don't ever use W functions anywhere else.

My understanding is that we use the W versions of the APIs and
immediately convert to UTF-8 to store internally. When we require
interaction in the other direction, we convert back to UTF-16. At
least, this is how we work with things like command line arguments and
files. As an example, see Process::GetArgumentVector.

>
>
>>
>>
>> > +  DWORD result = 0;
>> > +  DWORD valueSize = 0;
>> > +  // First just query for the required size.
>> > +  result = RegQueryValueEx(hkey, valueName, NULL, NULL, NULL,
>> > &valueSize);
>>
>> We should be caring about the key type as well, since we only want
>> string values.
>
> True, but at the same time since we're querying for the key by name, we
> already know what type it is.  I suppose it's possible that someone has a
> corrupted registry though with a matching keyname of a different type, but
> otherwise it's not possible to have two keys with the same value

Correct, but it's also possible that we find a key that's complete BS
from someone trying to mess with us. We shouldn't make assumptions
about the state of *anything* when we are trawling around in the
registry. Defense-in-depth more than anything. ;-)

~Aaron