Fix several bugs in r221220's new program finding code.
authorChandler Carruth <chandlerc@gmail.com>
Tue, 2 Dec 2014 00:52:01 +0000 (00:52 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Tue, 2 Dec 2014 00:52:01 +0000 (00:52 +0000)
commit84c0f6544647307714b267ffe197d5044f07e8b8
tree702b98df29d8868133a45d85f49daa015e6a2be2
parent7e32aa1015b0553a486af05780235ae60ac2df21
Fix several bugs in r221220's new program finding code.

In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.

This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.

I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D

Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223099 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Support/Unix/Program.inc
lib/Support/Windows/Program.inc