[llvm] r180035 - [Support] Fix argv string escape bug on Windows

[Reid Kleckner]

On Sat, Apr 27, 2013 at 2:59 PM, Dimitry Andric <dimitry at andric.com> wrote:
> Hi,
>
> The ProgramTest.cpp test always fails on FreeBSD (and any other BSD), since
> the part:
>
>   Path my_exe = Path::GetMainExecutable("SupportTests",
> &ProgramTestStringArg1);
>
> always results in 'my_exe' being empty there.  This is because the
> executable is not run from the PATH, so GetMainExecutable() cannot find it.
> Other OSes have different ways to get at the running executable name, so
> there are no failures there.
>
> As discussed a bit on IRC, there are several ways of improving this.  The
> most reasonable way would be to add something to
> llvm::cl::ParseCommandLineOptions() to make it save the original argv[0] (or
> the whole argv array) somewhere, and make it accessible via some sort of
> interface.  Currently it does store ProgramName in a static variable in
> lib/Support/CommandLine.cpp, but there is no way to get at it...

Yep, I thought about that but it seemed wrong to add this interface to
library code just for test code.

The static array isn't really suitable since it truncates to 80 chars.
 Saving argv[0] isn't good either since ParseCommandLine options
doesn't take or share ownership of the argv array.

> Another option would be to pass the actual program name as a macro during
> compilation, since the build system will know in advance exactly where the
> SupportTests executable is located.  This may be complicated with automake
> or CMake, though; I am not sure.

I'd rather take another option.

> Finally, as a minor detail, the ProgramTest.cpp file has its executable bit
> set.  This was probably inherited from a Windows file share?

Thanks, I'll fix that.

There's also apparently a __progname on *BSD, but it looks like it
doesn't include the relative path component.

I don't have access to a FreeBSD machine at the moment, so the best
way for me to fix this may be to save argv[0] in TestMain.cpp's
main().