Page MenuHomePhabricator

Properly handle short file names on the command line in Windows
ClosedPublic

Authored by amccarth on Jun 15 2016, 4:29 PM.

Details

Summary

This addresses: https://llvm.org/bugs/show_bug.cgi?id=28089

Some build systems use the short (8.3) file names on Windows, especially if the path has spaces in it. The shortening made it impossible for clang to distinguish between clang.exe, clang++.exe, and clang-cl.exe. So, in addition to expanding wildcards, the code now replaces short names with long ones.

Tested with ninja check-clang.

Diff Detail

Repository
rL LLVM

Event Timeline

amccarth updated this revision to Diff 60926.Jun 15 2016, 4:29 PM
amccarth retitled this revision from to Properly handle short file names on the command line in Windows.
amccarth updated this object.
amccarth added reviewers: majnemer, rnk.
amccarth added a subscriber: llvm-commits.
majnemer edited edge metadata.Jun 15 2016, 4:42 PM

Any reason not to perform the call to ExpandShortFileName in GetArgumentVector? I think we only need to do this for the first argument.

Any reason not to perform the call to ExpandShortFileName in GetArgumentVector? I think we only need to do this for the first argument.

I was trying to be complete by treating all the arguments the same way. Note that the existing code calls WildcardExpand on the first argument, even though that one seems really unlikely to have wildcards. And, if it does, you need to expand wild cards before expanding the short file names.

That said, I'm open to treating the first argument as a special case if you can convince me it is indeed special.

Any reason not to perform the call to ExpandShortFileName in GetArgumentVector? I think we only need to do this for the first argument.

I was trying to be complete by treating all the arguments the same way. Note that the existing code calls WildcardExpand on the first argument, even though that one seems really unlikely to have wildcards. And, if it does, you need to expand wild cards before expanding the short file names.

That said, I'm open to treating the first argument as a special case if you can convince me it is indeed special.

Here's my thinking:
argv[0] is special in that the compilers behavior is dependent on data before the extension suffix (.exe, etc.)
The compiler's behavior for the other argv[1..n] depends on the filename to suss out what mode the compiler should be in, this is not dependent on data before the suffix.

As an aside, I think it's quite strange that we look for wildcards in argv[0].

amccarth updated this revision to Diff 61015.Jun 16 2016, 1:22 PM
amccarth edited edge metadata.

Per the discussion, this version expands a short file name only in the first argument and applies the wildcard expansions only in the remaining arguments.

majnemer accepted this revision.Jun 16 2016, 1:55 PM
majnemer edited edge metadata.

LGTM w/ GetLongPathNameW > MAX_PATH addressed.

lib/Support/Windows/Process.inc
236–237 ↗(On Diff #61015)

Is an error code set for the case where Length > MAX_PATH? The MSDN docs seemed a little ambiguous.

This revision is now accepted and ready to land.Jun 16 2016, 1:55 PM
amccarth added inline comments.Jun 16 2016, 2:14 PM
lib/Support/Windows/Process.inc
236–237 ↗(On Diff #61015)

The way I read it is that, if the target buffer isn't big enough, then the return value is the necessary size (in code units). So I checked to see if it's bigger than MAX_PATH, since that's the capacity of the buffer.

In order to extend the buffer beyond MAX_PATH, we'd get into the realm of the \\?\ prefix nonsense. I assume there's lot of code in here that doesn't handle those, so if the expansion won't fit within MAX_PATH, I'm treating it as an error.

I believe GetLastError will return ERROR_NOT_ENOUGH_MEMORY or some other appropriate value in that case. I'll check that now and add a comment.

amccarth updated this revision to Diff 61037.Jun 16 2016, 2:50 PM
amccarth edited edge metadata.

Better error handling if the long name is longer than MAX_PATH.

amccarth marked 2 inline comments as done.Jun 16 2016, 2:52 PM
amccarth added inline comments.
lib/Support/Windows/Process.inc
236–237 ↗(On Diff #61037)

GetLastError was useless. If Length > LongName.capacity(), then the path in LongName is truncated and GetLastError returns ERROR_SUCCESS. So I've broken this case out and returned a more specific error code.

This revision was automatically updated to reflect the committed changes.
amccarth marked an inline comment as done.