[PATCH] D21420: Properly handle short file names on the command line in Windows
Robinson, Paul via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 16 18:11:08 PDT 2016
> -----Original Message-----
> From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf
> Of Adrian McCarthy via llvm-commits
> Sent: Thursday, June 16, 2016 2:14 PM
> To: amccarth at google.com; rnk at google.com; david.majnemer at gmail.com
> Cc: llvm-commits at lists.llvm.org
> Subject: Re: [PATCH] D21420: Properly handle short file names on the
> command line in Windows
> amccarth added inline comments.
> Comment at: lib/Support/Windows/Process.inc:236-237
> @@ +235,4 @@
> + DWORD Length = GetLongPathNameW(Arg, LongPath.data(),
> + if (Length == 0 || Length > MAX_PATH)
> + return mapWindowsError(GetLastError());
> + LongPath.set_size(Length);
> majnemer wrote:
> > Is an error code set for the case where `Length > MAX_PATH`? The MSDN
> docs seemed a little ambiguous.
> 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.
FYI, we have gone to some trouble to support \\?\ paths in Path.inc, or
convert to the long form as needed, for general path handling. But yes
I agree in practice you're unlikely to need it on the program filespec.
> 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.
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
More information about the llvm-commits